Jeff King [off-list ref] writes:
On Tue, Mar 27, 2012 at 12:16:36PM -0700, Junio C Hamano wrote:
quoted
Jeff King [off-list ref] writes:
quoted
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.
On Wed, Mar 28, 2012 at 10:42:26AM -0700, Junio C Hamano wrote:
quoted
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
Jeff King wrote:
On Wed, Mar 28, 2012 at 10:42:26AM -0700, Junio C Hamano wrote:
quoted
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
[...]
That sounds sensible to me. I think it involves writing our own
execvp, though, right?
If I understood Junio correctly, then checking for ENOENT and EACCES
should be enough.
Example: when I try
:; mkdir $HOME/cannotread
:; chmod -x $HOME/cannotread
:; echo nonsense >$HOME/bin/cat
:; chmod -x $HOME/bin/cat
:; PATH=$HOME/cannotread:$HOME/bin/cat:/usr/local/bin:/usr/bin:/bin
:; cat /etc/fstab
the shell uses /bin/cat without complaint.