Re: [RFC/PATCH] avoid SIGPIPE warnings for aliases

From: Junio C Hamano <gitster@pobox.com>
Date: Jan 4, 2013, 22:20 UTC
Message-ID: <7vsj6gsi7v.fsf@alter.siamese.dyndns.org>
In-Reply-To: <20130104124756.GA402@sigill.intra.peff.net>

Jeff King <peff@peff.net> writes:

Show 7 quoted lines

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

Show 7 quoted lines

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