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

[Vincent Lefevre <vincent@xxxxxxxxxx>]

On 2009-07-18 11:35:09 -0700, Bart Schaefer wrote:
> On Jul 18, 12:16pm, Vincent Lefevre wrote:
> } 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.

I didn't miss anything: the shell can still restore the previous
status before an exec.

> } 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.

According to my tests, bash *does* implement WCE. 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.

Is there any reason?

> } > 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.

Well, after re-reading, I agree Cracauer's advice is wrong here.
But it is fixable and I think that the other parts of his page are
correct. At least, IUE/WUE/WCE are defined under the context "There
are several ways to handle abortion of shell scripts when SIGINT is
received while a foreground child runs", so it is clear that the shell
*must* receive a SIGINT (this is also said near the beginning of the
page).

-- 
Vincent Lefèvre <vincent@xxxxxxxxxx> - Web: <http://www.vinc17.org/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/>
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)