Re: [PATCH 1/2] run-command: propagate EACCES errors to parent

[Jeff King <peff@peff.net>]

On Tue, Mar 27, 2012 at 11:24:02AM -0700, Junio C Hamano wrote:

> > Actually, there is a slight bending of the truth in the commit message.
> > bash implements its own execvp, and it will only return 126/EACCES if a
> > file is found via stat(), but is not executable. If there is an
> > inaccessible directory in the PATH (meaning that stat() will fail), it
> > will silently convert that to 127/ENOENT.
> 
> I am wondering what would happen if we treated EACCESS and ENOENT exactly
> the same way.  Wouldn't the four breakage scenarios in the cover letter
> end up being even better?  Case (3) will still say does-not-exist is not a
> git command (instead of "permission denied", which this patch gives), but
> your case (2) will see a much better diagnosis.

Yes, after writing my last message detailing all of the cases, I am
tempted to go that way. The downside is that it is more confusing if you
have a file in your PATH without the execute bit. IOW, we do not
differentiate the common mistake of "directory in PATH is not
accessible" from the uncommon "we found /usr/bin/foo, but it is not
executable by you". While the latter case is much less common, it would
be nice to continue to report EACCES.

Which leads us to either implementing our own execvp, or tracing through
the PATH after execvp fails (which amounts to basically the same thing).

-Peff