Given that the bug was introduced by Linus' patch (to fix a bug that anyway is in all shell implementations that do WCE) and that it's caused by a behaviour that seems to be specific to the Linux kernel (that the kernel seems to be messing up with the order of delivery of the SIGCHLD (or return from waitpid()) and SIGINT), we may want to bring the issue up to him.
Here, the behaviour could be seen as a kernel bug, since the child should clearly die *after* the SIGINT has been issued to the parent (since the ^C should insert the SIGINT in the signal queue of both parent and child processes at the same time) so it's wrong for SIGINT to be handled *after* waitpid() returns. But of course one can also argue that the order of signal delivery is not guaranteed in general anyway. IMO, the best approach would be to give up on WCE altogether which is more source of frustration anyway than it has ever helped. I live very well with a /bin/sh (dash) and interactive shell (zsh) that don't do it. WCE may be good in a perfect world where everything does it (everything that calls waitpid() without using system(3)), but if not, I hardly see the point. What's the point of bash doing it when sh, find -exec, xargs, watch, git (like in that emacs bug report) don't do it. it seems to me that finding another way to address it (like emacs approach of putting itself on its own in a new forground job if it's not already a process group leader) for the rare cases where it's useful (like the vi -> :! case) would be better. -- Stephane
