When receiving a signal, a process must kill itself using the same signal
sys.exit()ing 0, 1, 130, whatever will not signal to the calling program that we terminated in response to the signal
Best example: `for f in a b c; do bob deploy $f; done`, hitting Ctrl+C should interrupt Bob and stop the bash loop, but does not with `sys.exit()`:
# for x in php-7.3.13 php-7.3.13 php-7.3.13; do bob build $x; done
Fetching dependencies... found 1:
- libraries/libc-client-2007f
Building formula php-7.3.13 in /tmp/bob-35s7cr5z:
-----> Building php-7.3.13...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 18.7M 100 18.7M 0 0 7435k 0 0:00:02 0:00:02 --:--:-- 7434k
^Cool.
Fetching dependencies... found 1:
- libraries/libc-client-2007f
Building formula php-7.3.13 in /tmp/bob-vmuko2ra:
-----> Building php-7.3.13...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
20 18.7M 20 3887k 0 0 7479k 0 0:00:02 --:--:-- 0:00:02 7476k^Cool.
Fetching dependencies... found 1:
- libraries/libc-client-2007f
Building formula php-7.3.13 in /tmp/bob-p2t8as81:
-----> Building php-7.3.13...
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
4 18.7M 4 943k 0 0 3599k 0 0:00:05 --:--:-- 0:00:05 3588k^Cool.
We want instead to have the loop end upon the first Ctrl+C.
That's only possible if Bash knows that we exited in response to Ctrl+C (=SIGINT), then it'll also terminate the loop
Bash will report the exit status as 128+$signal, so 130 for SIGINT, but sys.exit(130) does not to the same thing - the value of 130 is simply bash's representation
Killing ourselves with the signal number that we are aborting in response to does all this correctly, and bash will see the right WIFSIGNALED() status of our program, not WIFEXITED()
David Zuelke
kennethreitz