Re: [BUG] Bash not reacting to Ctrl-C

[Linus Torvalds]

On Fri, Feb 11, 2011 at 1:16 PM, Chet Ramey <chet.ramey@case.edu> wrote:
>
> In the meantime, read Martin Cracauer's description of the issue.
> http://www.cons.org/cracauer/sigint.html.

This is now the second time in the thread that this has been quoted,
but bash doesn't even FOLLOW the recommendations in that web-page, so
I don't understand why you and Illia point to it. You violate the
thing egregiously.

Here, let me quote the relevant bit:

  Take no action when SIGINT is received while you wait for a child.
You make a note of the fact that you did receive it, though.

and note the "while you wait for a child" part.

And the fact is, that is not at all what bash does. What bash does is
"Take no action when SIGINT is received
_even_if_you_didn't_wait_for_the_child_".

Not "during the wait". That's the problem. There's a HUGE race
condition in there, and in particular, if the child was quick and
already exited, but bash just hadn't gotten around to noticing it it
yet, bash will still ignore the ^C that happened after the child had
already exited. See?

So let's imagine that you're waiting for GNU emacs, and GNU emacs uses
^C for its own handling. Yes, in that case you need to ignore it. But
in that case, when you get SIGINT, you'll actually get an EINTR from
the waitpid system call.

The other case is that the child process was quick and already exited.
You get ^C, but the child never did. When you do the waitpid(), you'll
never get the EINTR, because there was no actual wait.

See the difference? And see how bash doesn't actually do what that
"Proper handling of SIGINT" page says to do.

                          Linus