Jeff King <peff@xxxxxxxx> writes: > On Tue, Mar 27, 2012 at 12:16:36PM -0700, Junio C Hamano wrote: > >> Jeff King <peff@xxxxxxxx> writes: >> >> > If git receives an EACCES error while trying to execute an >> > external command, we currently give up and report the error. >> > However, the EACCES may be caused by an inaccessible >> > directory in the user's PATH. >> >> Regardless of EACCES/ENOENT change we discussed, the observable behaviour >> should be testable. Something like this? > > Yes, though I held back on writing tests, because I don't think we've > quite decided what the behavior _should_ be. Should we be > differentiating "chmod -x /bin/ls" from "chmod -x /bin"? Should we be > continuing alias lookup on EACCES? Should we print edit-distance > suggestions on EACCES? I am leaning to think that it would be the least surprising if we treat as if /bin/ls does not even exist if /bin is not searchable. If /bin/ls is unreadable or unexecutable but /bin is searchable, then we _know_ it exists, and we follow the usual exec*p() rule to ignore it so "git ls" would try to find an alias and when all else fails will give the edit distance suggestions but should exclude /bin/ls from candidates. If /bin itself is unsearchable, we do not even know what it contains, so it is needless to say that /bin/ls will not be part of suggestion candidates. That way, the only thing people _could_ complain about is "I have a directory $HOME/sillybin in my $PATH but do not have an executable bit on it. When I try to run 'git stupid', 'git-stupid' in that diretory is not executed, and I do not even get an error message to point out that I am missing the executable bit on $HOME/sillybin directory". And you can say "Ah, just like the shell. So make sure you have necessary permission bits on things". Very easy and straightforward to explain and understand. -- 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