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 <c...@elego.de>


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

Sending in case someone finds it useful or interesting. Feel free to
ignore it or make fun of it if you want.

 run-command.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/run-command.c b/run-command.c
index 1101ef7..97e6960 100644
--- a/run-command.c
+++ b/run-command.c
@@ -85,6 +85,7 @@ static char *locate_in_PATH(const char *file)
        const char *p = getenv("PATH");
        struct strbuf buf = STRBUF_INIT;
+       struct stat st;
        if (!p || !*p)
                return NULL;
@@ -101,8 +102,9 @@ static char *locate_in_PATH(const char *file)
                strbuf_addstr(&buf, file);
-               if (!access(buf.buf, F_OK))
+               if (!stat(buf.buf, &st) && !S_ISDIR(st.st_mode)) {
                        return strbuf_detach(&buf, NULL);
+               }
                if (!*end)

To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to