Re: [PATCH] pager: exit without error on SIGPIPE

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Feb 3, 2021, 02:45 UTC
Message-ID: <87r1lxeuoj.fsf@evledraar.gmail.com>
In-Reply-To: <xmqqczxjhwgv.fsf@gitster.c.googlers.com>

On Tue, Feb 02 2021, Junio C Hamano wrote:

Show 25 quoted lines

> Junio C Hamano <gitster@pobox.com> writes:
>
>> Sorry, but you still have lost me---I do not see if/why we even care
>> about atexit codepath.  As far as the end users are concered, they
>> are running "git" and observing the exit code from "git".  There,
>> reporting that "git" was killed by SIGPIPE, instead of exiting
>> normally, is not something they want to hear about after quitting
>> their pager, and that is why the signal reception codepath matters.
>
> (something I noticed that I left unsaid...)
>
> On the other hand, "git" spawns not just pager but other
> subprocesses (e.g. "hooks"), and it is entirely up to us what to do
> with the exit code from them.  When we care about making an external
> effect (e.g. post-$action hooks that are run for their side effects),
> we can ignore their exit status just fine.
>
> And I do not see why the "we waited before leaving, and noticed the
> pager exited with non-zero status" that we could notice in the
> atexit codepath has to be so special.  We _could_ (modulo the "exit
> there is not portable" you noted) make our exit status reflect that,
> but I do not think it is all that important a "failure" (as opposed
> to, say, we tried to show a commit message but failed to recode it
> into utf-8, or we tried to spawn the pager but failed to start a
> process) to clobber _our_ exit status with pager's exit status.

Because your patch upthread makes git's exit code on pager failure a function of how your PIPE_BUF happens to be consumed on your OS.

You can see this if you do this:

    diff --git a/pager.c b/pager.c
    index ee435de6756..5124124ac36 100644
    --- a/pager.c
    +++ b/pager.c
    @@ -30,0 +31 @@ static void wait_for_pager_atexit(void)
    +       trace2_region_enter_printf("pager", "wait_for_pager_atexit", the_repository, "%d", 0);
    @@ -35,0 +37 @@ static void wait_for_pager_signal(int signo)
    +       trace2_region_enter_printf("pager", "wait_for_pager_signal", the_repository, "%d", 1);

And then e.g.:

    GIT_TRACE2_EVENT=/tmp/trace2.json ~/g/git/git -c core.pager="less; exit 1" log -100; echo $?

On my laptop & screen size I get around ~20 page lenghts with less before I get to the end.

If I quit on the first page I get an exit code of 141, ditto the second, on everything from the 3rd forward I get an exit code of 0. Because at that point git's/the OS/pipe buffers etc. have flushed the rest to the pager.

So:

 1. With something like your patch we'd get an exit code of !0 on pager
    failure only if the user won the PIPE_BUF roulette.

 2. With finishing up my "WIP/PATCH v2 5/5" we'd get consistent exit
    codes carried down, but that patch is insanity already, and
    finishing it would be even crazier.

So I haven't been advocating for #2, just the #0 of "I don't really see the problem with the current behavior of SIGHUP, maybe configure your shell?".

B.t.w. to <5772995f-c887-7f13-6b5f-dc44f4477dcb@kdbg.org> in the side-thread: Having a smarter pager than just less isn't really all that unusual, e.g. it's very handy on a remote system to type commands interactively but sloooowly, but then configure a pager with some combination of an ssh tunnel + nc + remote system's screen so you can browse around without every search/page up/down taking 1-2 seconds.

It's also nice when a thing like that can quit as fast as possible when it gets SIGHUP, not wait on the exit code of the spawned program, which may involve tearing down an ssh session or whatever.

But I digress.

Getting back to the point, whatever anyone thinks of returning SIGHUP as we do now or not, I think it's bonkers to ignore SIGHUP and *then* return a non-zero *only in the non-atexit case*.

That just means that if you do have a broken pager you're going to get flaky exits depending on the state of our flushed buffers, who's going to be helped by such a fickle exit code?

So if we're going to change the behavior to not return SIGHUP, and don't want to refactor our entire atexit() handling in #2 to be guaranteed to pass down the pager's exit code, I don't see how anything except the approach of just exit(0) in that case makes sense, which is what Denton Liu's patch initially suggested doing.