Re: [PATCH 2/2] git: continue alias lookup on EACCES errors

[Jeff King <peff@peff.net>]

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. OTOH, I think we already have an
implementation in compat/mingw.

> 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.

Agreed.

-Peff