Thread (2 messages) flat view 2 messages, 2 authors, 2016-06-15

Re: [PATCH] run-command: treat inaccessible directories as ENOENT

From: Frans Klaver <hidden>
Date: 2016-06-15 22:53:25

On Fri, Mar 30, 2012 at 9:52 AM, Jeff King [off-list ref] wrote:
 1. I split the find-in-path function so that Frans can build on it
    with further checks if he wants. However, note that it will need a
    little more refactoring; it finds the first entry in the PATH,
    whereas I think he would want the first executable entry
    (admittedly, having a non-executable entry followed by an
    executable one which _also_ fails for a different reason is a
    pretty wild corner case).
Thanks. I think this corner case is something to fix when someone is
running into it. Bash doesn't cover this case either (stops looking at
the first found entry) so I would go as far as saying that it doesn't
happen.

 2. I pulled the test from what Junio posted earlier. I started to
    write a full test script that checked each of the cases I
    mentioned earlier. However, in all but the alias case (which is
    what is tested here), the behavior is really only distinguishable
    by the error messages, and I didn't want to get into testing what
    strerror(EACCES) prints. I can re-roll if we really want to go
    there.
I wouldn't think there is much point in testing strerror output.


+test_expect_success POSIXPERM 'unreadable directory in PATH' '
+       mkdir local-command &&
+       test_when_finished "chmod u+rwx local-command && rm -fr local-command" &&
+       git config alias.nitfol "!echo frotz" &&
+       chmod a-rx local-command &&
+       (
+               PATH=./local-command:$PATH &&
+               git nitfol >actual
+       ) &&
+       echo frotz >expect &&
+       test_cmp expect actual
+'
+
 test_done
--
1.7.9.5.7.g11b89
Hadn't looked into Junio's test earlier (probably missed it entirely),
but isn't it rather more sensible from a unit-test perspective to see
if start_command returns 127 instead of 128 in this specific case?
Aside from that, this test doesn't seem to fit in t0061, looking at
the t???? guidelines.

Rest looks sensible to me.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help