[REGRESSION] git-wrapper to run-commands codepath regression

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.