On Mon, Mar 26, 2012 at 04:48:29PM -0700, James Pickens wrote:
> I'm not sure if this should be considered a bug or not, but I've noticed that
> when my $PATH contains an inaccessible directory, Git fails to execute aliases.
> For example:
>
> git config alias.l log
> git l
> # works fine
> PATH=boguspath:$PATH
> mkdir boguspath
> chmod 000 boguspath
> git l
> # fatal: cannot exec 'git-l': Permission denied
This seems to come up about once a year. The short of it is that execve
will return EACCESS whether the file exists is not actually executable
by you, or if you have an inaccessible element in your PATH. execvp will
continue the search if it sees EACCESS, but will return EACCESS if it
finds nothing. So git just sees the EACCESS and doesn't know if you
have bogus entries in your PATH or if there is a permissions problem
with your executable files.
For something like a shell, it's not that big a deal; either way, you
couldn't execute the command in question. For git, it matters more
because we first try to exec an external command, and then fall back to
an alias (because externals take precedence over aliases).
So basically our options are:
1. Start treating EACCESS silently as ENOENT. The downside is that we
fail to report the proper error when the file really does have
permissions problems (we would say "command not found", but that is
misleading).
2. Implement our own execvp, differentiating between "path not
available for looking in" and "we found the command, but there was
a permissions problem". I think somebody was working on this a few
months ago (search for "add exeecvp failure diagnostics") but it
seems to have fizzled.
3. If we get an EACCESS, remember it, try to do the alias lookup, and
then if that fails, report the "Permission denied" error (not
"command not found"). That is following the spirit of what execvp
does (it will find later entries in the PATH if they are there, but
otherwise will remember the EACCESS error).
>From what I can tell, dash uses stock execvp, and ends up closest to
(3). Bash seems to have implemented their own path lookup, as it will
distinguish between the two cases as in (2):
$ mkdir /tmp/foo
$ chmod 0 /tmp/foo
$ PATH=/tmp/foo:$PATH
$ dash -c does-not-exist
dash: 1: does-not-exist: Permission denied
$ bash -c does-not-exist
bash: does-not-exist: command not found
$ chmod 755 /tmp/foo
$ >/tmp/foo/does-not-exist
$ chmod 0 /tmp/foo/does-not-exist
$ dash -c does-not-exist
dash: 1: does-not-exist: Permission denied
$ bash -c does-not-exist
bash: /tmp/foo/does-not-exist: Permission denied
I think the general feeling last time this came up was "why not just
remove the cruft from your PATH?" But I would personally be OK with
option (3) above, and it is probably not that hard to implement.
-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