All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jonathan Nieder <jrnieder@gmail.com>
To: Frans Klaver <fransklaver@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Johannes Sixt <j6t@kdbg.org>,
	git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH 5/5] run-command: Error out if interpreter not found
Date: Fri, 27 Jan 2012 03:41:45 -0600	[thread overview]
Message-ID: <20120127094145.GA2611@burratino> (raw)
In-Reply-To: <CAH6sp9O7P8bmYA66fY754mn=ogp8OP1i3KQuE_hnrTY46nNAxw@mail.gmail.com>

Frans Klaver wrote:

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

See [1] for an example of a recent patch touching the relevant
code path.

For example: if I run "git --paginate foo", foo is an alias for bar,
and the "[pager] bar" configuration is set to point to "otherpager",
then without this safety git launches the default pager in preparation
for running git-foo, receives ENOENT from execvp("git-foo"), and then
the pager has already been launched and it is too late to launch
otherpager instead.

> On Fri, Jan 27, 2012 at 9:48 AM, Jonathan Nieder <jrnieder@gmail.com> wrote:

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

Exactly.

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

I see.

Well, as I said, I don't know. :)  And I don't want to give false
hopes --- it's perfectly possible and not even unlikely that this is a
dead end and any patch in this direction will turn out not to be a
good idea and not applied.

That's part of why I was really grateful to Hannes for the reminder to
take a step back for a moment and consider whether it's worth it.
Maybe there's another way or a more targetted way to take care of the
motivational original confusing scenario that leads to execvp errors.
(By the way, can you remind me which one that was?)

Jonathan

[1] http://thread.gmane.org/gmane.comp.version-control.git/179635

  reply	other threads:[~2012-01-27  9:42 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-24 22:32 [PATCH 0/6 v3] Add execvp failure diagnostics Frans Klaver
2012-01-24 22:32 ` [PATCH 1/5] t0061: Fix incorrect indentation Frans Klaver
2012-01-24 22:39   ` Junio C Hamano
2012-01-24 22:40   ` Jonathan Nieder
2012-01-25  6:27     ` Frans Klaver
2012-01-25  7:00       ` Junio C Hamano
2012-01-25  7:08         ` Frans Klaver
2012-01-25  8:08       ` Frans Klaver
2012-01-24 22:32 ` [PATCH 2/5] t0061: Add tests Frans Klaver
2012-01-24 22:56   ` Jonathan Nieder
2012-01-25  6:47     ` Frans Klaver
2012-01-24 22:32 ` [PATCH 3/5] run-command: Elaborate execvp error checking Frans Klaver
2012-01-24 23:22   ` Jonathan Nieder
2012-01-25  7:09     ` Frans Klaver
2012-01-25 19:22       ` Jonathan Nieder
2012-01-25 22:48         ` Frans Klaver
2012-01-25 19:03   ` Johannes Sixt
2012-01-25 22:59     ` Frans Klaver
2012-01-24 22:32 ` [PATCH 4/5] run-command: Warn if PATH entry cannot be searched Frans Klaver
2012-01-24 22:32 ` [PATCH 5/5] run-command: Error out if interpreter not found Frans Klaver
2012-01-24 23:24   ` Jonathan Nieder
2012-01-25  7:12     ` Frans Klaver
2012-01-25 18:55       ` Johannes Sixt
2012-01-25 23:09         ` Frans Klaver
2012-01-26 19:32         ` Junio C Hamano
2012-01-27  8:29           ` Frans Klaver
2012-01-27  8:48             ` Jonathan Nieder
2012-01-27  9:11               ` Frans Klaver
2012-01-27  9:41                 ` Jonathan Nieder [this message]
2012-01-27 11:46                   ` Frans Klaver
2012-02-04 21:31                   ` Frans Klaver

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120127094145.GA2611@burratino \
    --to=jrnieder@gmail.com \
    --cc=fransklaver@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.