run-command: encode signal death as a positive integer
authorJeff King <peff@peff.net>
Sat, 5 Jan 2013 14:49:49 +0000 (09:49 -0500)
committerJunio C Hamano <gitster@pobox.com>
Sun, 6 Jan 2013 19:09:18 +0000 (11:09 -0800)
When a sub-command dies due to a signal, we encode the
signal number into the numeric exit status as "signal -
128". This is easy to identify (versus a regular positive
error code), and when cast to an unsigned integer (e.g., by
feeding it to exit), matches what a POSIX shell would return
when reporting a signal death in $? or through its own exit
code.

So we have a negative value inside the code, but once it
passes across an exit() barrier, it looks positive (and any
code we receive from a sub-shell will have the positive
form). E.g., death by SIGPIPE (signal 13) will look like
-115 to us in inside git, but will end up as 141 when we
call exit() with it. And a program killed by SIGPIPE but run
via the shell will come to us with an exit code of 141.

Unfortunately, this means that when the "use_shell" option
is set, we need to be on the lookout for _both_ forms. We
might or might not have actually invoked the shell (because
we optimize out some useless shell calls). If we didn't invoke
the shell, we will will see the sub-process's signal death
directly, and run-command converts it into a negative value.
But if we did invoke the shell, we will see the shell's
128+signal exit status. To be thorough, we would need to
check both, or cast the value to an unsigned char (after
checking that it is not -1, which is a magic error value).

Fortunately, most callsites do not care at all whether the
exit was from a code or from a signal; they merely check for
a non-zero status, and sometimes propagate the error via
exit(). But for the callers that do care, we can make life
slightly easier by just using the consistent positive form.

This actually fixes two minor bugs:

  1. In launch_editor, we check whether the editor died from
     SIGINT or SIGQUIT. But we checked only the negative
     form, meaning that we would fail to notice a signal
     death exit code which was propagated through the shell.

  2. In handle_alias, we assume that a negative return value
     from run_command means that errno tells us something
     interesting (like a fork failure, or ENOENT).
     Otherwise, we simply propagate the exit code. Negative
     signal death codes confuse us, and we print a useless
     "unable to run alias 'foo': Success" message. By
     encoding signal deaths using the positive form, the
     existing code just propagates it as it would a normal
     non-zero exit code.

The downside is that callers of run_command can no longer
differentiate between a signal received directly by the
sub-process, and one propagated. However, no caller
currently cares, and since we already optimize out some
calls to the shell under the hood, that distinction is not
something that should be relied upon by callers.

Fix the same logic in t/test-terminal.perl for consistency [jc:
raised by Jonathan in the discussion].

Signed-off-by: Jeff King <peff@peff.net>
Acked-by: Johannes Sixt <j6t@kdbg.org>
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Documentation/technical/api-run-command.txt
editor.c
run-command.c
t/test-terminal.perl

index f18b4f4817448530a5adbe2c8835bb7791add42a..5d7d7f2d32f58f8682ca5efb2fd98fe7e74247dd 100644 (file)
@@ -55,10 +55,8 @@ The functions above do the following:
   non-zero.
 
 . If the program terminated due to a signal, then the return value is the
-  signal number - 128, ie. it is negative and so indicates an unusual
-  condition; a diagnostic is printed. This return value can be passed to
-  exit(2), which will report the same code to the parent process that a
-  POSIX shell's $? would report for a program that died from the signal.
+  signal number + 128, ie. the same value that a POSIX shell's $? would
+  report.  A diagnostic is printed.
 
 
 `start_async`::
index 065a7abf2ffc0df61c35e0740e95caa5af14b229..27bdecdaf3d99d3179737e07be971d2458408660 100644 (file)
--- a/editor.c
+++ b/editor.c
@@ -51,7 +51,7 @@ int launch_editor(const char *path, struct strbuf *buffer, const char *const *en
                sigchain_push(SIGINT, SIG_IGN);
                sigchain_push(SIGQUIT, SIG_IGN);
                ret = finish_command(&p);
-               sig = ret + 128;
+               sig = ret - 128;
                sigchain_pop(SIGINT);
                sigchain_pop(SIGQUIT);
                if (sig == SIGINT || sig == SIGQUIT)
index 24eaad5c66c1742602347c42c71d279297aabc2a..04712191e8acfbf000c526a5b1b0a80541e8e174 100644 (file)
@@ -249,7 +249,7 @@ static int wait_or_whine(pid_t pid, const char *argv0)
                 * mimics the exit code that a POSIX shell would report for
                 * a program that died from this signal.
                 */
-               code -= 128;
+               code += 128;
        } else if (WIFEXITED(status)) {
                code = WEXITSTATUS(status);
                /*
index 10172aee18292b50aa24b3a8694b5383c1cfd98e..1fb373f25bac42648a0779ffd42f1ae0eaec359a 100755 (executable)
@@ -31,7 +31,7 @@ sub finish_child {
        } elsif ($? & 127) {
                my $code = $? & 127;
                warn "died of signal $code";
-               return $code - 128;
+               return $code + 128;
        } else {
                return $? >> 8;
        }