git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <peff@peff.net>
To: Jonathan Nieder <jrnieder@gmail.com>
Cc: Junio C Hamano <gitster@pobox.com>, Johannes Sixt <j6t@kdbg.org>,
	git@vger.kernel.org, Bart Trojanowski <bart@jukie.net>
Subject: Re: [PATCH] run-command: encode signal death as a positive integer
Date: Sat, 5 Jan 2013 18:12:49 -0500	[thread overview]
Message-ID: <20130105231248.GA4140@sigill.intra.peff.net> (raw)
In-Reply-To: <20130105221909.GA3247@elie.Belkin>

On Sat, Jan 05, 2013 at 02:19:09PM -0800, Jonathan Nieder wrote:

> >  Documentation/technical/api-run-command.txt | 6 ++----
> >  editor.c                                    | 2 +-
> >  run-command.c                               | 2 +-
> >  3 files changed, 4 insertions(+), 6 deletions(-)
> 
> t/test-terminal.perl imitates the same logic.  It doesn't check for
> anything other than whether the exit status is 0, but maybe it would
> be worth squashing in the below as a futureproofing measure
> nonetheless.

Yeah, I think so. As you say, it does not matter, but it makes sense to
keep our conventions consistent.

> Aside from the launch_editor bugfix, the only observable effects of
> the above patch I can find are some changed error messages:
> 
> 	error: external filter cat failed -126
> 	-> error: external filter cat failed 130
> 
> 	warning: svnrdump, returned -126
> 	-> warning: svnrdump, returned 130
> 
> Those messages are equally senseless before and after the patch, so
> for what it's worth,

Thanks. I agree that change isn't a big deal (I would argue the positive
return is slightly more coherent as it matches what the shell would
report, but I really think user-facing errors should probably not even
mention the exact exit code, as it is just noise most of the time, and
we already complain about signals in wait_or_whine).

I did try auditing the callers of finish_command (and run_command) to
make sure I wasn't regressing anybody, but there are a lot of call
sites. In some cases we immediately say:

  if (finish_command(&child))
          die("failed...");

which is obviously unaffected. But in many cases we pass the exit code
up through several levels. It usually just ends up in exit() or being
collapsed to an error boolean, which is fine, but I may have missed a
spot where it matters. I'd expecting cooking this patch for a while
would flush out any I missed.

> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>

Thanks (and to J6t) for the review.

-Peff

  reply	other threads:[~2013-01-05 23:13 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-04 12:47 [RFC/PATCH] avoid SIGPIPE warnings for aliases Jeff King
2013-01-04 16:55 ` Johannes Sixt
2013-01-04 21:25   ` Jeff King
2013-01-04 22:20 ` Junio C Hamano
2013-01-05 14:03   ` Jeff King
2013-01-05 14:49     ` [PATCH] run-command: encode signal death as a positive integer Jeff King
2013-01-05 19:50       ` Johannes Sixt
2013-01-05 22:19       ` Jonathan Nieder
2013-01-05 23:12         ` Jeff King [this message]
2013-01-05 23:58           ` Jonathan Nieder
2013-01-06  7:05       ` Junio C Hamano
2013-01-09 20:48 ` [RFC/PATCH] avoid SIGPIPE warnings for aliases Junio C Hamano
2013-01-09 20:51   ` Jeff King
2013-01-09 21:49     ` Junio C Hamano
2013-01-10  0:18       ` Jonathan Nieder
2013-01-10  0:39         ` Junio C Hamano
2013-01-10 11:26         ` Jeff King
2013-01-10 20:22           ` Junio C Hamano
2013-01-10 21:39             ` Jeff King
2013-01-10 21:52             ` Johannes Sixt
2013-01-10 22:51               ` Junio C Hamano
2013-01-10 10:49       ` Jeff King
2014-07-21  6:45 ` mimimimi

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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=20130105231248.GA4140@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=bart@jukie.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=j6t@kdbg.org \
    --cc=jrnieder@gmail.com \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).