2015-09-18 16:14:39 +0100, Stephane Chazelas: [...] > In: > > bash -c 'sh -c "trap exit INT; sleep 10; :"; echo hi' > > If I press Ctrl-C, I still see "hi". [...]
Jilles provided with the explanation at http://unix.stackexchange.com/a/230731 with a link to: http://www.cons.org/cracauer/sigint.html Which makes sense. Now, IMO a few things could be improved: 1- it would be nice if it could be clearly documented 2- if the shell received SIGINT, then I'd argue the currently running process returning with a "status" such that WIFEXITED(status)&& WEXITSTATUS(status) == SIGINT + 0200 should be another case where bash (and AT&T ksh and FreeBSD sh) should exit as well (by killing themselves with SIGINT or exit(SIGINT + 0200)). That's my: > That sounds like a bad idea, especially considering that it > doesn't exit either if the process returns with exit code 130 > upon receiving that SIGINT. For instance: > > For instance, in: > > bash -c 'mksh -c "sleep 10; :"; echo hi' > > Upon pressing Ctrl-C, mksh handles the SIGINT and exits with > 130 (as opposed to dying of a SIGINT), so bash doesn't exit > (sometimes only on Debian). 3. There still seems to be a bug in bash in that > On Debian with 4.3.42(1)-release (x86_64-pc-linux-gnu), that > seems to happen only in something like 80% of the time. Cheers, Stephane
