Re: Bug? Bad permissions in $PATH breaks Git aliases

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> This seems to come up about once a year....
> ...
> So basically our options are:
>
>   1. Start treating EACCESS silently as ENOENT. The downside is that we
>      fail to report the proper error when the file really does have
>      permissions problems (we would say "command not found", but that is
>      misleading).
>
>   2. Implement our own execvp, differentiating between "path not
>      available for looking in" and "we found the command, but there was
>      a permissions problem". I think somebody was working on this a few
>      months ago (search for "add exeecvp failure diagnostics") but it
>      seems to have fizzled.
>
>   3. If we get an EACCESS, remember it, try to do the alias lookup, and
>      then if that fails, report the "Permission denied" error (not
>      "command not found"). That is following the spirit of what execvp
>      does (it will find later entries in the PATH if they are there, but
>      otherwise will remember the EACCESS error).
>
> From what I can tell, dash uses stock execvp, and ends up closest to
> (3). Bash seems to have implemented their own path lookup, as it will
> distinguish between the two cases as in (2):
> ...
> I think the general feeling last time this came up was "why not just
> remove the cruft from your PATH?" But I would personally be OK with
> option (3) above, and it is probably not that hard to implement.

http://thread.gmane.org/gmane.comp.version-control.git/171755/focus=171838
shows that it was almost exactly a year ago; we tried (2) and nobody liked
it.

I got an impression from the discussion in it that #3 may give confusing
messages to the end users, but I didn't think the issues through.