Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #11557

Re: SIGINT handling

Show key headers only | View raw

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

Back to gnu.bash.bug | Previous | Next | Find similar

Thread

Re: SIGINT handling Stephane Chazelas <stephane.chazelas@gmail.com> - 2015-09-24 14:57 +0100

csiph-web