Re: [PATCH] pager: exit without error on SIGPIPE
- From
Johannes Sixt <j6t@kdbg.org>
- Date
- Feb 3, 2021, 17:07 UTC
- Message-ID
- <aa672f2b-6886-a2bf-5129-f10f4e488961@kdbg.org>
- In-Reply-To
- <xmqqwnvqdsax.fsf@gitster.c.googlers.com>
Am 02.02.21 um 23:21 schrieb Junio C Hamano:
Show 22 quoted lines
> Johannes Sixt <j6t@kdbg.org> writes: > >>> Anyway, my opinion in the message you are responding to was that the >>> exit status of the pager subprocess wait_for_pager_atexit() finds >>> does not matter, and there is no reason to overly complicate the >>> implementation like the comments in Ævar's [v2 5/5] implies, and it >>> is sufficient to just hide the fact in wait_for_pager_signal() that >>> we got SIGPIPE. I am not sure if you are agreeing with me, or are >>> showing me where/why I was wrong. >> >> We are agreeing that the SIGPIPE should not be reported. >> >> We may be disagreeing whether it is good or bad that git's exit code is >> overridden by the pager's exit code, which Ævar wanted to implement, >> IIUC. I think that is reasonable and I base my opinion on the comparison >> with the pipeline `git log | less`, where git's exit code is ignored. > > I guess we are then in agreement---I do think it makes sense to send > the true exit code from the pager as the exit code from the pager to > the trace output, which is what the early part of Ævar's patch does, > but I do not think the exit code of the pager should affect the exit > code from "git log" as a whole.
Then we do not agree. The exit code of `git log | less` is ignored, and I regard `git -p log` just as a short-hand for that.
That said, I don't care a lot about the exit code. When a pager is in the game, we are talking about an interactive command invocation, and what the exit code of that is, is irrelevant in practice.
The only thing I care is that git does not die due to a SIGPIPE when the pager is closed early.
-- Hannes