Re: git fails with a broken pipe when one quits the pager

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Mon, Feb 01 2021, Chris Torek wrote:

>> On 2021-01-31 21:49:49 +0100, Ævar Arnfjörð Bjarmason wrote:
>> > ... That we're returning an exit code per getting a SIGHUP here
>> > is a feature. Consider:
>> >
>> >     git -c core.pager=/bin/false log && echo showed you the output
>
> This example has a minor flaw: it should use `git -c core.pager=/bin/true`,
> probably.

FWIW it doesn't have a flaw It should be /bin/false, not /bin/true. See
this reply in a side-thread:
https://lore.kernel.org/git/87im7cng42.fsf@xxxxxxxxxxxxxxxxxxx/

I.e. part of the point here (which I realize I forgot to articulate...)
is that we have a hard reliance on SIGHUP to report *any* pager failures
as a matter of the current implementation.

Part of that has to do with internal git implementation details, i.e. we
get the exit code for the pager either in an atexit() handler (we've
already picked the exit code) or when handling a signal.

Perhaps we could do better there and e.g. exit with <num> if the pager
exits with <num>. I don't know what's the conventional behavior in that
case.

But in any case, we exit with SIGPIPE in those cases in any reasonable
failure mode. That is, unless the pager consumed all the output, and
*then* died that is.

I submitted
https://lore.kernel.org/git/20210201144921.8664-1-avarab@xxxxxxxxx/ to
try to address the lack of testing around this, which has tests for the
true/false case.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux