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.