Re: [PATCH] report which $PATH entry had trouble running execvp(3)

[Jonathan Nieder <jrnieder@gmail.com>]

Hi,

Junio C Hamano wrote:

> You can add your own custom subcommand 'frotz' to the system by adding
> 'git-frotz' in a directory somewhere in your $PATH environment variable.
> When you ask "git frotz" from the command line, "git-frotz" is run via
> execvp(3).
>
> Three plausible scenarios that the execvp(3) would fail for us are:
[...]
> The first one is easy to understand and to rectify.  Most likely, the user
> made a typo, either on the command line, or when creating the custom
> subcommand.  However, the latter two cases are harder to notice, as we do
> not report 'git-frotz' in which directory we had trouble with.  We could
> do better if we implemented the command search behaviour of execvp(3)
> ourselves.

My first reaction was the same as Hannes's.  I suppose I would be
happier about something like an optional dependency on something
generic like libexplain[1] (though I'm not thrilled about the style of
its error messages).  If we are to implement it ourselves, using
standard execvp and then trying to track down a guess for the cause
after it fails might be okay.

[1] http://libexplain.sourceforge.net/

I was also reminded that anyone writing scripts following the advice
of POSIX (meaning no #!) would find their custom git commands broken.
Luckily that is easily fixed by using execvp with absolute path.

A part of this is tempting: as Jeff mentioned, it would be nice to
avoid commit_pager_choice when checking for a dashed external before
executing an alias to an internal command that doesn't want a pager
(see v1.7.2~16^2, git --paginate: paginate external commands again,
2010-07-14).  Hm.