On Wed, Dec 23, 2015 at 09:37:04PM +0100, Johannes Sixt wrote:
> >--- a/git.c
> >+++ b/git.c
> >@@ -252,7 +252,7 @@ static int handle_alias(int *argcp, const char ***argv)
> > alias_argv[argc] = NULL;
> >
> > ret = run_command_v_opt(alias_argv, RUN_USING_SHELL);
> >- if (ret >= 0) /* normal exit */
> >+ if (ret != -1) /* normal exit */
>
> Why does this make a difference? We only ever return -1, zero, or a positive
> value from run_command/finish_command/wait_or_whine, as far as I can see.
Yeah, you're right. This bit predates 709ca73 (run-command: encode
signal death as a positive integer, 2013-01-05), which came out of the
same discussion. So I'd agree this hunk can simply be dropped.
That leaves the ignoring of SIGPIPE in wait_or_whine. I started to
rewrite the commit message to drop the first hunk, but I found I
couldn't replicate the problem in the second either!
Doing:
GIT_PAGER=false git -c alias.foo='!git log -p' foo
doesn't trigger it. We run the alias through a shell, so we see only the
munged "141" value from the shell's exit code.
Something like:
GIT_PAGER=false git -p -c alias.foo='!yes' foo
does generate the error message. But we've redirected stderr into the
pager at that point, so by definition it can never be shown.
So I think we would need a case where:
- the outer git doesn't run the pager that dies; instead the pager is
run inside the alias. But...
- inside the alias cannot be a shell pipeline, since "foo | less" will
report the exit code of "less", not "foo" (we make special arrangements
in git to propagate the exit code of "foo"). So it pretty much has
to be a git invocation inside the alias. But...
- The git invocation will convert signal death in the sub-process into
141, like a shell would.
So I'm not sure if this is triggerable at all with an alias.
I did manage to trigger it with an external command, like:
$ cat $(which git-yes)
#!/bin/sh
# This _has_ to be exec, otherwise the shell converts SIGPIPE death
# into 141.
exec yes
and then if you run your _own_ pager, like this:
$ git yes | false
error: git-yes died of signal 13
you see it. But if git starts the pager, you don't:
$ GIT_PAGER=false git -p yes
Because the stderr of the outer git process is going to the same dead
pipe.
So my takeaways are:
1. Complaining about signal death in general is going to be flaky,
because it's so easy for shells or git to rewrite the exit code and
not trigger WIFSIGNALED() in the first place.
2. I doubt anybody is actually seeing this in practice anymore. But
maybe I am misunderstanding something in Duy's series that changes
this.
-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
