Hi,

Jeff King wrote:

> When a sub-command dies due to a signal, we encode the
> signal number into the numeric exit status as "signal -
> 128".
[...]
> 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).
[...]
> Unfortunately, this means that when the "use_shell" option
> is set, we need to be on the lookout for _both_ forms.
[...]
>             for the callers that do care, we can make life
> slightly easier by just using the consistent positive form.

Makes perfect sense.

>  Documentation/technical/api-run-command.txt | 6 ++----
>  editor.c                                    | 2 +-
>  run-command.c                               | 2 +-
>  3 files changed, 4 insertions(+), 6 deletions(-)

t/test-terminal.perl imitates the same logic.  It doesn't check for
anything other than whether the exit status is 0, but maybe it would
be worth squashing in the below as a futureproofing measure
nonetheless.

Aside from the launch_editor bugfix, the only observable effects of
the above patch I can find are some changed error messages:

        error: external filter cat failed -126
        -> error: external filter cat failed 130

        warning: svnrdump, returned -126
        -> warning: svnrdump, returned 130

Those messages are equally senseless before and after the patch, so
for what it's worth,
Reviewed-by: Jonathan Nieder <jrnie...@gmail.com>

Thanks.

diff --git i/t/test-terminal.perl w/t/test-terminal.perl
index 10172aee..1fb373f2 100755
--- i/t/test-terminal.perl
+++ w/t/test-terminal.perl
@@ -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;
        }
--
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

Reply via email to