On Fri, Jan 15 2021, Vincent Lefevre wrote: > I had reported the following bug at > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=914896 > > It still occurs with Git 2.30.0. > > Some git commands with a lot of output fail with a broken pipe when > one quits the pager (without going to the end of the output). > > For instance, in zsh: > > cventin% setopt PRINT_EXIT_VALUE > cventin% git log > zsh: broken pipe git log > cventin% echo $? > 141 > cventin% > > This is annoying[...] Yes it's annoying, but the annoying output is from zsh, not git. Consider a smarter implementation like: case $__exit_status in 0) __exit_emoji=😀;; 1) __exit_emoji=☹️ ;; 141) __exit_emoji=🤕 ;; [...] Then put the $__exit_emoji in your $PS1 prompt, now when you 'q' in a pager you know the difference between having quit at the full output being emitted or not. > And of course, I don't want to hide error messages by default, because > this would hide *real* errors. Isn't the solution to this that your shell stops reporting failures due to SIGPIPE in such a prominent way then? > The broken pipe is internally expected, thus should not be reported > by git. > > Just to be clear: this broken pipe should be discarded only when git > uses its builtin pager feature, not with a general pipe, where the > error may be important. > > For instance, > > $ { git log ; echo "Exit status: $?" >&2 ; } | true > > should still output > > Exit status: 141 I don't get it, how is it less meaningful when git itself invokes the pager? In both cases the exit code means the same thing, that something in a pipe wasn't fully consumed being signalled to calling processes is the point of SIGPIPE.
