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

From: Jonathan Nieder <jrnieder@gmail.com>
Date: Apr 20, 2011, 11:21 UTC
Message-ID: <20110420112122.GA6580@elie>
In-Reply-To: <7vaafl371q.fsf_-_@alter.siamese.dyndns.org>

Hi,

Junio C Hamano wrote:

Show 6 quoted lines

> 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:

[...]

Show 6 quoted lines

> 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.