From: Eric Sunshine Date: Wed, 23 Dec 2015 16:17:57 GMT Subject: Re: [PATCH v2 0/3] nd/clear-gitenv-upon-use-of-alias Message-ID: In-Reply-To: <20151223093700.GA13386@sigill.intra.peff.net> On Wed, Dec 23, 2015 at 4:37 AM, Jeff King wrote: > Subject: [PATCH] avoid SIGPIPE warnings for aliases > > When git executes an alias that specifies an external > command, it will complain if the alias dies due to a signal. > This is usually a good thing, as signal deaths are > unexpected. However, SIGPIPE is not unexpected for many > commands which produce a lot of output; it is intended that > the user closing the pager would kill them them via SIGPIPE. s/them them/them/ > As a result, the user might see annoying messages in a > scenario like this: > > $ cat ~/.gitconfig > [alias] > lgbase = log --some-options > lg = !git lgbase --more-options > lg2 = !git lgbase --other-options > > $ git lg -p > [user hits 'q' to exit pager] > error: git lgbase --more-options died of signal 13 > fatal: While expanding alias 'lg': 'git lgbase --more-options': Success > > Many users won't see this, because we execute the external > command with the shell, and a POSIX shell will silently > rewrite the signal-death exit code into 128+signal, and we > will treat it like a normal exit code. However, this does > not always happen: > > 1. If the sub-command does not have shell metacharacters, > we will skip the shell and exec it directly, getting > the signal code. > > 2. Some shells do not do this rewriting; for example, > setting SHELL_PATH set to zsh will reveal this problem. > > This patch squelches the message, and lets git exit silently > (with the same exit code that a shell would use in case of a > signal). > > The first line of the message comes from run-command's > wait_or_whine. To silence that message, we remain quiet > anytime we see SIGPIPE. > > The second line comes from handle_alias itself. It calls > die_errno whenever run_command returns a negative value. > However, only -1 indicates a syscall error where errno has > something useful (note that it says the useless "success" > above). Instead, we treat negative returns from run_command > (except for -1) as a normal code to be passed to exit. > > Signed-off-by: Jeff King