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. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html