[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: SIGINT handling
From: |
Stephane Chazelas |
Subject: |
Re: SIGINT handling |
Date: |
Sat, 19 Sep 2015 21:36:28 +0100 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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
- SIGINT handling, Stephane Chazelas, 2015/09/18
- Re: SIGINT handling,
Stephane Chazelas <=
- Re: SIGINT handling, Stephane Chazelas, 2015/09/21
- Re: SIGINT handling, Chet Ramey, 2015/09/21
- Re: SIGINT handling, Stephane Chazelas, 2015/09/21
- Re: SIGINT handling, Stephane Chazelas, 2015/09/21
- Re: SIGINT handling, Chet Ramey, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22
- Re: SIGINT handling, Stephane Chazelas, 2015/09/22