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

[Martin Cracauer <cracauer@cons.org>]

Hi, a friend pointed me to this discussion and I took it as an
opportunity to fix some minor issues with my SIGINT page.

I'd like to comment on this one:

Bart Schaefer wrote:
> 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.

You are correct (except that the numeric exit of 130 means nothing,
you have to use WIFSIGNALED but I assume you know that and just
shortcut it for the message).

There would be two ways of dealing with this:

1) when a child got killed with SIGINT, always abort the script
2) do that only when the shell itself also had received a SIGINT while
   that child was executing in the foreground

I have actually implemented 2) in FreeBSD's shell and bash also does
2).  However, I had skipped over that detail when writing the webpage.
The have has been corrected.

(let me know if you want credit on the page)

%%

More bits from the discussion:
>> 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.

Looks like it's more complicated.

Both FreeBSD and Linux place both the shell and emacs in the same
progress group.

However, using strace on Linux you can see the SIGINT delivered to the
shell if you do

#! /bin/sh
cat
echo survived

And Control-C out of the cat.

And not when the callee is emacs.

On first sight it looks like the Linux kernel changes semantics based
on whether the terminal is in cooked mode or not.  Possibly in an
attempt to help a bit with the "what to do on SIGINT in interactive
programs" mess we are dealing with here.

If so, that explains why Linux users never flamed about the
wrong-exit-after-emacs problem.  If the kernel never tells the shell
anything about the SIGINT when the foreground program is in curses
mode the problem won't appear.

If so, that would be bad news for shellscripts calling programs that
do curses but just exit on SIGINT (lynx comes to mind).

Thanks
Martin
-- 
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <cracauer@cons.org>   http://www.cons.org/cracauer/
FreeBSD - where you want to go, today.      http://www.freebsd.org/