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

On Fri, Jan 27, 2012 at 9:48 AM, Jonathan Nieder [off-list ref] wrote:

quoted

                                           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.

Hannes' reaction and Junio's to his didn't give me the impression they
even saw a possibility.

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.

Good. That's something we can work on.

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.

Just for my understanding: before a command is executed, a pager
(less/more or so) is started? We want to avoid starting the pager if
we won't be able to execute the command?

I want to like (b), but the downside seems unacceptable.

The downside being: having to figure out what execvp is going to do?
That would be tantamount to writing your own execvp.

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.

Given the above information, I'm happy to work on this to see if we
can mould it into something usable. Since the impact seems to go
beyond figuring out why execvp failed, I'm probably going to need some
help.

For now, I'll go through your suggestions and see what it produces.
We'll go from there.

Thanks for the heads-up.