Subject: Re: [PATCH 5/5] run-command: Error out if interpreter not found

From: Jonathan Nieder <[email-masked]>
Date: Fri, 27 Jan 2012 02:48:45 -0600

(+cc: Jeff because mentioning a pagination side-issue [*])
Frans Klaver wrote:

>                                            If this was pretty much
> going to be /dev/null'ed from the beginning, I'd rather have heard it
> after my first patches.

Almost always when a developer has an itch, it is _possible_ to
massage a patch that scratches it into something acceptable to others.
And whether it is worth the trouble in terms of time is something that
only that developer can decide.

So no, I would not say these patches were not doomed from the
beginning.  However, I certainly agree that in their current form they
are more complicated than the use case justifies.

There is a tension between requirements that leaves me oddly
uncomfortable with the series:

a. on one hand, it would be nice to preserve all the current features
   of execvp(), which makes the approach of only doing post-mortem
   analysis after a failed execvp appealing;

b. on the other hand, it would be nice [*] to avoid launching a pager
   only in order to call execvp for a command that does not exist when
   the fallback might be to an alias to a command that does not want a
   pager.  That would require figuring out in advance that execvp
   would fail with ENOENT and missing out on possible system extensions
   that allow execvp to run shell built-in commands not existing on
   the filesystem.

I want to like (b), but the downside seems unacceptable.  I honestly
don't know if something like (a) would be a good idea if well
executed, so I was happy to have the opportunity to try to help
massage these patches into a form that would make the answer more
obvious.