Am 24.06.2016 um 21:43 schrieb Jeff King:
In POSIX shells, a program which exits due to a signal
generally has an exit code of 128 plus the signal number.
However, some platforms do other things. ksh uses 256 plus
the signal number, and on Windows, all signals are just "3".
That's not true, see below.
I didn't get into the weirdness of SIGPIPE on Windows here, but I think
this is probably a first step toward handling it better. E.g., it may be
that test_match_signal should respect 128 (or even any code) when we are
checking for SIGPIPE.
The Windows behavior is most closely described as having signal(SIGPIPE,
SIG_IGN) at the very beginning of the program.
+# Returns true if the numeric exit code in "$2" represents the expected signal
+# in "$1". Signals should be given numerically.
+test_match_signal () {
+ if test "$2" = "$((128 + $1))"
+ then
+ # POSIX
+ return 0
+ elif test "$2" = "$((256 + $1))"
+ then
+ # ksh
+ return 0
+ elif test "$2" = "3"; then
+ # Windows
You meant well here, but this is close to pointless as a general check.
We check for this exit code in t0005 because there program termination
happens via raise(), which on Window just calls exit(3). This exit code
is not an indication that something related to SIGPIPE (or any signal)
happened.
IMO there is too much danger to trigger a false positive if exit code 3
is treated special in this generality.
+ return 0
+ fi
+ return 1
+}
-- Hannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html