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 02:48:45 -0600	[thread overview]
Message-ID: <20120127084845.GC806@burratino> (raw)
In-Reply-To: <CAH6sp9NEnkDY-BCccW9VM3waxg8sG8zV5-rVAuMUfZ9rji4-Qw@mail.gmail.com>

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

  reply	other threads:[~2012-01-27  8:48 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 [this message]
2012-01-27  9:11               ` Frans Klaver
2012-01-27  9:41                 ` Jonathan Nieder
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=20120127084845.GC806@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.