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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html