Re: [PATCH] run-command: don't try to execute directories

Carlos Martín Nieto [off-list ref] writes:

When looking through $PATH to try to find an external command,
locate_in_PATH doesn't check that it's trying to execute a file. Add a
check to make sure we won't try to execute a directory.

This also stops us from looking further and maybe finding that the
user meant an alias, as in the case where the user has
/home/user/bin/git-foo/git-foo.pl and an alias

    [alias] foo = !/home/user/bin/git-foo/git-foo.pl

Running 'git foo' will currently will try to execute ~/bin/git-foo and
fail because you can't execute a directory. By making sure we don't do
that, we realise that it's an alias and do the right thing

Signed-off-by: Carlos Martín Nieto <redacted>

---

This comes from a case in #git. Not sure if this is worth it, or the
better solution is just to say no to dirs in $PATH.

After writing all of that, I thought to check the shell, and indeed

    % git-foo
    zsh: permission denied: git-foo

so if the shell doesn't do it, the benefits probably don't outweigh
having a dozen stat instead of access calls. strace reveals that zsh
does what git currently does. bash uses stat and says 'command not
found'.

Hrm, I do not use zsh but it does not seem to reproduce for me.

	$ mkdir -p /var/tmp/xx/git
        $ zsh
        % PATH=/var/tmp/xx:$PATH
        % type git
        git is /home/junio/bin/git
        % git version
        git version 1.8.0.rc0.45.g7ce8dc5
	% zsh --version
	zsh 4.3.10 (x86_64-unknown-linux-gnu)

So we used to say "if it exists and accessible, return that".  Now
we say "if it exists and is not a directory, return that".

I have to wonder what would happen if it exists as a non-directory
but we cannot access it.  Is that a regression?

 		if (!*end)
 			break;