git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: git@vger.kernel.org, Bart Trojanowski <bart@jukie.net>
Subject: Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases
Date: Fri, 04 Jan 2013 14:20:52 -0800	[thread overview]
Message-ID: <7vsj6gsi7v.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20130104124756.GA402@sigill.intra.peff.net> (Jeff King's message of "Fri, 4 Jan 2013 07:47:56 -0500")

Jeff King <peff@peff.net> writes:

> I have two reservations with this patch:
>
>   1. We are ignoring SIGPIPE all the time. For an alias that is calling
>      "log", that is fine. But if pack-objects dies on the server side,
>      seeing that it died from SIGPIPE is useful data, and we are
>      squelching that. Maybe callers of run-command should have to pass
>      an "ignore SIGPIPE" flag?

What should this do:

    GIT_PAGER='head -n 1' git -p -c alias.o='!cat longfile' o

Should it behave just like

    cat longfile | head -n 1

or should it behave differently?

I am having a feeling that whatever external command given as the
value of alias.$cmd should choose what error status it wants to be
reported.

>   2. The die_errno in handle_alias is definitely wrong. Even if we want
>      to print a message for signal death, showing errno is bogus unless
>      the return value was -1. But is it the right thing to just pass the
>      negative value straight to exit()? It works, but it is depending on
>      the fact that (unsigned char)(ret & 0xff) behaves in a certain way
>      (i.e., that we are on a twos-complement platform, and -13 becomes
>      141).

Isn't that what POSIX.1 guarantees us, though?

    The value of status may be 0, EXIT_SUCCESS, EXIT_FAILURE, or any
    other value, though only the least significant 8 bits (that is,
    status & 0377) shall be available to a waiting parent process.

  parent reply	other threads:[~2013-01-04 22:21 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 [this message]
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
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

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

  git send-email \
    --in-reply-to=7vsj6gsi7v.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=bart@jukie.net \
    --cc=git@vger.kernel.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 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 NNTP newsgroup(s).