Jeff King <peff@xxxxxxxx> writes: > On Wed, Mar 28, 2012 at 10:42:26AM -0700, Junio C Hamano wrote: > >> > 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 sounds sensible to me. I think it involves writing our own > execvp, though, right? If we use stock execvp, we can't tell the > difference between the two cases. The stock exec*p() will not hit "/bin/ls" in either case, so we will give "'ls' is not a git command", without having to differenciate it. That is what I meant by "we follow the usual rule to ignore it". We already have the code necessary to enumerate the possible commands from components of the PATH in order to give suggestion, so we can run it after seeing exec*p() failure to see if we did not see any "ls", or we saw "ls" but it was not executable. No need to penalize the normal case, no? -- 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