There appears to be a regression in the codepath between git wrapper and
run_commands API.
$ T=/var/tmp/test-commands
$ mkdir $T
$ cat >$T/git-hello <<\-EOF
#!/bin/sh
echo hello
EOF
$ chmod +x $T/git-hello
$ oPATH=$PATH
$ PATH=$T:$PATH
$ export PATH
$ git hello
hello
So far, I added a "hello" subcommand to "git", and it runs correctly.
Now, when I make the script non-executable, this is what I get from
'maint':
$ chmod a-x $T/git-hello
$ git hello
fatal: cannot exec 'git-hello': Permission denied
But with 'master', we get a disturbing output:
$ git hello
fatal: $
Note that we can observe the same regression if you instead make $T
unreadable with:
$ chmod 755 $T/git-hello ;# make it executable again
$ chmod a-rwx $T ;# but that directory cannot be read
$ git hello
So that is the "regression" part.
The following is a tangent that was brought up at $work.
Some people might argue that we should skip $T/git-hello in the last case
and try to find git-hello in a later directory listed in $PATH, but I do
not personally think that is a right thing to do. It would make the
problem harder to diagnose, and more importantly, the fact that the user
listed $T earlier in the $PATH is a strong indication that the user wants
the scripts in $T override the scripts with the same name in directories
that appear later in the $PATH, and we should report when that is not
happening, either
(1) when $T/git-st was found but was not executable; or
(2) when we cannot read $T and we cannot even tell $T/git-st exists or
not.
So I think it is Ok to be silent only when we see ENOENT like the current
code does.
I am somewhat sympathetic to the case (2) above, but not sympathetic
enough to suggest changing the current behaviour. In fact, I would say
if we treat EACCES the same way as we treat ENOENT, it would be a bug.
When your $HOME is mounted over NFS on two different machines, it is
perfectly fine to have a directory that exists on one machine but not on
other machines in $PATH, and it is reasonable to expect such a directory
to be skipped silently without complaints.
That situation, with a small stretch of imagination, can be extended to a
case where a directory early in your $PATH that you are using on one
machine for your private git-script correctly on one machine is owned by
somebody else, used for other purposes, and most importantly you have no
control on it on another machine, and you could argue that these two cases
are similar.
It is _not_ quite similar, though. Such an "early path component is a
random place I do not control" arrangement is a total security risk, and
we shouldn't be bending backwards to support it. Instead, we should be
actively discouraging it. That is why I said I am not sympathetic enough
above.
--
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