From Stéphane Chazelas's reply at https://unix.stackexchange.com/a/230568
Ideally, we'd want to report to our parent that we died of a SIGINT
(so that if it's another bash script for instance, that bash script is
also interrupted). Doing an exit 130 is not the same as dying of
SIGINT (though some shells will set $? to same value for both cases),
however it's often used to report a death by SIGINT (on systems where
SIGINT is 2 which is most).However for bash, ksh93 or FreeBSD sh, that doesn't work. That 130
exit status is not considered as a death by SIGINT and a parent script
would not abort there.
- Regarding "Doing an exit 130 is not the same as dying of SIGINT",
what are the differences between them? - Why is it that "for bash, ksh93 or FreeBSD sh, that doesn't work. That
130 exit status is not considered as a death by SIGINT"?
From Bash manual:
When a command terminates on a fatal signal whose number is N, Bash uses the value 128+N as the exit status
The signal number of SIGINT is 2, so the exit status of a command
terminating on SIGINT is 130.
So it seems to me that doing an exit 130 is the same as dying of SIGINT, and that
130 exit status is considered as a death by SIGINT.
Thanks.
Best Answer
The 130 (128+SIGINT) you see in
$?
after the last command died of a SIGINT is a simplified representation of its exit status made by some shells likebash
. Other shells will use different representations (like 256+signum in ksh93, 128+256+signum in yash, textual representations likesigint
orsigquit+core
inrc
/es
). See Default exit code when process is terminated? for more details on that.A process can wait for its child process and query its status:
_exit()
system call (with which exit code)To do that, they use one of the
wait()
,waitpid()
,waitid()
(see also obsoletewait3()
,wait4()
) or a handler on the SIGCHLD system call.Those system calls return all that information above. (Except for
waitid()
on some system, only the lowest 8 bits of the number passed to_exit()
for child that terminate normally are available though).But
bash
(and most Bourne-like and csh-like shells) bundle all that information in a 8 bit number for$?
($?
is the lowest 8 bits of the exit code for processes that terminate normally, and 128+signum it it was killed or suspended or trapped, all the other information is not available). So obviously, there's some information being lost. In particular, through$?
alone, one can't tell if a process did a_exit(130)
or died of a SIGINT.bash
knows when a process is being killed obviously. For example when background processes are killed, you see:But in
$?
, it doesn't give you enough information to tell whether it was killed by SIGINT or it called_exit(130)
.Since most shells do that transformation, applications know better than doing
_exit(number_greater_than_127)
for anything but reporting a death by signal though.Still if a process does a
_exit(130)
, the process waiting for that process will detect that that process terminated normally, not that it was killed by a signal. In C,WIFEXITED()
will return true,WIFSIGNALED()
will return false.bash
itself will not consider the process as having died of a SIGINT (even though it lets you think it might have through$?
containing the same value as if it had died of a SIGINT).So, that will not trigger the special handling of SIGINT that
bash
does. In a script, bothbash
and the currently running command in the script will receive a SIGINT upon^C
(as they're both in the same process group).bash
dies upon receiving SIGINT only if the command it is waiting for also died of a SIGINT (the idea being that if for instance in your script, you run vi or less and use ^C to abort something there which doesn't makevi
/less
die, your script doesn't die upon returning quittingvi
/less
later on).If that command
bash
is waiting for does a_exit(130)
in a handler of SIGINT,bash
will not die upon that SIGINT (it will not consider itself as having been interrupted because it doesn't believe the child has been interrupted).That's why when you want to report a death by SIGINT, that you have indeed been interrupted even though you are actually doing some extra processing upon receiving that signal in a handler, you should not do a
_exit(130)
, but actually kill yourself with SIGINT (after having restored the default handler for SIGINT). In a shell, that's with: