[PATCH/RFC] sane_execvp(): ignore non-directory on PATH

[PATCH/RFC] sane_execvp(): ignore non-directory on PATH

[Junio C Hamano]

When you have a non-directory on your PATH, a funny thing happens:

	$ PATH=$PATH:/bin/sh git foo
	fatal: cannot exec 'git-foo': Not a directory?

Worse yet, as real commands always take precedence over aliases,
this behaviour interacts rather badly with them:

	$ PATH=$PATH:/bin/sh git -c alias.foo=show git foo -s
	fatal: cannot exec 'git-foo': Not a directory?

This is because an ENOTDIR error from the underlying execvp(2) is
reported back to the caller of our sane_execvp() wrapper as-is.  By
translating it to ENOENT, just like the case where we _might_ have
the command in an unreadable directory, fixes it.  Without an alias,
we would get

	git: 'foo' is not a git command. See 'git --help'.

and we use the 'foo' alias when it is available.

Signed-off-by: Junio C Hamano <gitster@pobox.com>
---

 * We can view this as a follow-up to 38f865c (run-command: treat
   inaccessible directories as ENOENT, 2012-03-30).

 run-command.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/run-command.c b/run-command.c
index 805d41f..f9b7db2 100644
--- a/run-command.c
+++ b/run-command.c
@@ -77,6 +77,8 @@ int sane_execvp(const char *file, char * const argv[])
 	 */
 	if (errno == EACCES && !strchr(file, '/'))
 		errno = exists_in_PATH(file) ? EACCES : ENOENT;
+	else if (errno == ENOTDIR && !strchr(file, '/'))
+		errno = ENOENT;
 	return -1;
 }
 

Re: [PATCH/RFC] sane_execvp(): ignore non-directory on PATH

[Jeff King]

On Tue, Jul 31, 2012 at 12:46:13PM -0700, Junio C Hamano wrote:

> When you have a non-directory on your PATH, a funny thing happens:
> 
> 	$ PATH=$PATH:/bin/sh git foo
> 	fatal: cannot exec 'git-foo': Not a directory?
> 
> Worse yet, as real commands always take precedence over aliases,
> this behaviour interacts rather badly with them:
> 
> 	$ PATH=$PATH:/bin/sh git -c alias.foo=show git foo -s
> 	fatal: cannot exec 'git-foo': Not a directory?
> 
> This is because an ENOTDIR error from the underlying execvp(2) is
> reported back to the caller of our sane_execvp() wrapper as-is.  By
> translating it to ENOENT, just like the case where we _might_ have
> the command in an unreadable directory, fixes it.  Without an alias,
> we would get
> 
> 	git: 'foo' is not a git command. See 'git --help'.
> 
> and we use the 'foo' alias when it is available.
> 
> Signed-off-by: Junio C Hamano <gitster@pobox.com>
> ---
> 
>  * We can view this as a follow-up to 38f865c (run-command: treat
>    inaccessible directories as ENOENT, 2012-03-30).

Hrm. EACCES is somewhat special, in that the underlying execvp will
continue after seeing EACCES, and will only report it back to us if we
don't eventually find a good candidate.

Is ENOTDIR the same? IOW, If I do:

  PATH=/bin/cat:/bin
  ls

will I still run "ls"? Testing on my glibc system says "yes", which I
think makes this a sane thing to do (if it were not the case and ENOTDIR
causes an early return, then that ENOENT is kind of a lie, since we
simply don't know the answer).

> diff --git a/run-command.c b/run-command.c
> index 805d41f..f9b7db2 100644
> --- a/run-command.c
> +++ b/run-command.c
> @@ -77,6 +77,8 @@ int sane_execvp(const char *file, char * const argv[])
>  	 */
>  	if (errno == EACCES && !strchr(file, '/'))
>  		errno = exists_in_PATH(file) ? EACCES : ENOENT;
> +	else if (errno == ENOTDIR && !strchr(file, '/'))
> +		errno = ENOENT;
>  	return -1;

Yay. I remember the original 38f865c going through several iterations,
and I am glad we took the time to end up with one that made adding this
case in so simple.

-Peff