Re: zsh 4.3.10 terminates with SIGINT when one types Ctrl-G in emacs under Mac OS X

[Bart Schaefer <schaefer@brasslantern.com>]

Part 2 of my reply, in which I argue philosophy rather than address the
specific shell problem.

On Jul 18, 12:16pm, Vincent Lefevre wrote:
} Subject: Re: zsh 4.3.10 terminates with SIGINT when one types Ctrl-G in em
}
} On 2009-07-17 22:29:36 -0700, Bart Schaefer wrote:
} > The point I believe Cracauer is overlooking is that the CALLER of the
} > shell script may have specified that SIGINT is to be ignored.  SIG_IGN
} > is supposed to be inherited by child processes; but to implement WUE
} > or WCE, the shell must itself either ignore or handle SIGINT, which
} > may contradict what the caller has requested.
} 
} I don't think that the caller should enforce what its children should
} do. Many programs will set their own SIGINT handler, even if the caller
} chose to ignore this signal.

You've missed the point.  SIG_IGN is by definition been inherited from
parent to child, and this is deliberately preserved across exec.  The
parent doesn't *enforce* this -- the child is *allowed* to set up a
handler of its own once it gets control -- but the mere fact that the
execv'd program is a shell should not void the inherited signal settings.
The shell might merely be an intermediary that's going to exec itself
out of existence, and the programmer of the parent should be able to
expect that the inherited signal settings make it through.

} Anyway, even though bash implements WCE,

Except that bash *DOESN'T* implement WCE, at least not the way that it
is defined in Cracauer's web page.  See below.

} it ignores SIGINT if the caller chose to ignore it; also when executing
} a process, it restores the trap to the default behavior, in case it was
} ignored (that's another difference with zsh).

And that's a case where I think the zsh behavior is in fact preferable.
 
} > Further I think Cracauer is very wrong here:
} > 
} >   Do nothing special when SIGINT appears while you wait for a child. You
} >   don't even have to remember that one happened.
} >   ...
} >   Look at WIFSIGNALED(status) and WTERMSIG(status) to tell whether the
} >   child says "I exited on SIGINT: in my opinion the user wants the
} >   shellscript to be discontinued".
} > 
} > This is plain nonsense.
} > 
} > Not only does this potentially contradict a caller's explicit request
} > to ignore SIGINT, but the script should not exit 130 every time any
} > child exits 130.  It should exit only when SIGINT was received *by the
} > script*.  "kill -INT ..." of the child should not cause the shell to
} > behave as if it was interrupted.  Try it with bash.
} 
} It seems that bash behaves correctly in all those cases.

Exactly -- which it would not if it followed Cracauer's advice; he's
wrong, and I'm not going to advocate that zsh adopt the behavior that
he describes.

} > Having said all that, I also looked at what it would take to implement
} > WCE as an option.  There are two complications here:
} > 
} > (1) There's a race condition as to whether the shell receives SIGINT
} > or SIGCHLD first.  With enough trials I can get it to happen either
} > way, though the vast majority of the time the SIGINT wins.
} 
} How does bash handle that?

It must handle it the way zsh 4.2.6 NO_TRAPS_ASYNC does, that is, by
blocking SIGINT (without changing the handler behavior) while waiting for
a child, then unblocking so the signal comes through after the waited-
for child exits.  This resolves the race in favor of always getting the
SIGCHLD first, and therefore the shell can always exit when it receives
the SIGINT (or never exit when it does not receive it).

} BTW, I wonder why typing Ctrl-g in emacs sends SIGINT to the parent
} under Mac OS X, but not under Linux.

Some ancestry of BSD vs. SYSV tty process group semantics, I expect.