In part, see Exit status codes greater than — possible? The WIFSIGNALED stuff tells you that a process was signalled, but there's a problem for the shell encoding that, and it does it by encoding a signalled exit status as 128 + signal number (129 for HUP, 130 for INT, etc). To demonstrate shell and signal exit statuses:
$ cat killme.sh
#!/bin/bash
kill ${1:-"-INT"} $$
$ ./killme.sh -HUP; echo $?
Hangup: 1
129
$ ./killme.sh -TERM; echo $?
Terminated: 15
143
$ ./killme.sh -QUIT; echo $?
0
$ ./killme.sh -PIPE; echo $?
141
$ ulimit -a
core file size (blocks, -c) 0
...
$
This more or less justifies my '128+signum' claim (the -QUIT
behaviour is unexpected, but explainable after a fashion — it normally dumps core, but didn't because ulimit
has them disabled).
In bash
, you can get 'a list of exit status values from the processes in the most-recently-executed foreground pipeline (which may contain only a single command)' via the array $PIPESTATUS
. For example:
$ ./killme.sh | exit 31
$ echo ${PIPESTATUS[*]}
130 31
$
This corresponds to the 130 exit status for SIGINT (2) plus the explicit exit status 31. Note the notation: ${PIPESTATUS[0]}
with the braces around the indexing. Double quotes and things work like $*
vs $@
vs "$*"
vs "$@"
for getting all the values in the array.
Applied to your two-part pipeline, you should be able to test:
if [[ ${PIPESTATUS[0]} == 134 ]]
then : FuseIO crash with SIGABRT
fi
Without the | tee
, you can simply test $?
:
if [[ $? > 128 && $? < 160 ]]
then : died a signalled death (probably)
else : died an ordinary death
fi
The 160 here is also an informed guess; it should be 128+SIGRTMAX. Note that if a process does exit 135
, it will be treated as if it was signalled (even if it does not).