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

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

[Martin Cracauer]

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/

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

[Bart Schaefer]

On Jul 22,  2:18pm, Martin Cracauer wrote:
} 
} Hi, a friend pointed me to this discussion and I took it as an
} opportunity to fix some minor issues with my SIGINT page.
} 
} 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)

Credit me if you like, but it's not necessary.

Did you also see Eric Blake's assertion that the shell must not un-ignore
a signal if it "starts life" with the signal ignored?  That's a "trap"
command restriction I'd never discovered before (and one I'm not very
happy about).
 
} 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.

I suspect it's more subtle than that ... e.g., it may be that on linux,
the SIGINT isn't coming from the terminal driver at all.

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

[Philippe Troin]

I've missed the beginning of the discussion, so excuse me if I restate
some points...

Bart Schaefer <schaefer@brasslantern.com> writes:

> Did you also see Eric Blake's assertion that the shell must not un-ignore
> a signal if it "starts life" with the signal ignored?  That's a "trap"
> command restriction I'd never discovered before (and one I'm not very
> happy about).

I would agree with that for non-interactive shells (that is zsh
interpreting a script).  However not resetting at least the terminal
signals (INT, QUIT, TTIN, TTOU, TSTP, CONT, HUP) to their default
settings (SIG_IGN) for interactive sessions could expose you to a lot
of trouble.  

> } 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.
> 
> I suspect it's more subtle than that ... e.g., it may be that on linux,
> the SIGINT isn't coming from the terminal driver at all.

Please enligthen me on this one...

Phil.

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

[Bart Schaefer]

On Jul 25, 11:24pm, Philippe Troin wrote:
}
} > } 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.
} > 
} > I suspect it's more subtle than that ... e.g., it may be that on linux,
} > the SIGINT isn't coming from the terminal driver at all.
} 
} Please enligthen me on this one...

Well, I'm speculating because I don't really know what emacs does with
the terminal on different architectures, but for example it might put
the terminal in raw mode and do its own I/O, then send the emacs process
group a signal when emacs reads a character that matches in interrupt
character definition.

That sure seems more sensible to me than trapping SIGINT and treating
it as the input of a ^C when doing keymap processing.

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

[Martin Cracauer]

Bart Schaefer wrote on Sat, Jul 25, 2009 at 11:58:11AM -0700: 
> On Jul 22,  2:18pm, Martin Cracauer wrote:
> } 
> } Hi, a friend pointed me to this discussion and I took it as an
> } opportunity to fix some minor issues with my SIGINT page.
> } 
> } 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)
> 
> Credit me if you like, but it's not necessary.
> 
> Did you also see Eric Blake's assertion that the shell must not un-ignore
> a signal if it "starts life" with the signal ignored?  That's a "trap"
> command restriction I'd never discovered before (and one I'm not very
> happy about).

I think that goes without saying but I can as well include it.

In fact this would be useful if somebody want to change a
shellscript's behavior to not abort more than the current program on
SIGINT and go forward with the next statement in the script.

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

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

[Bart Schaefer]

On Jul 27,  7:10pm, Martin Cracauer wrote:
} Subject: Re: zsh 4.3.10 terminates with SIGINT when one types Ctrl-G in em
}
} Bart Schaefer wrote on Sat, Jul 25, 2009 at 11:58:11AM -0700: 
} > Did you also see Eric Blake's assertion that the shell must not
} > un-ignore a signal if it "starts life" with the signal ignored?
} 
} In fact this would be useful if somebody want to change a
} shellscript's behavior to not abort more than the current program on
} SIGINT and go forward with the next statement in the script.

No; if the shell doesn't un-ignore the signal, then any program that
is started from the script will also still have SIGINT ignored, and
(unless *that* program re-handles the signal) neither the script nor
its children will be interruptible.

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

[Vincent Lefevre]

On 2009-07-22 02:58:37 +0000, Eric Blake wrote:
> POSIX requires that if a shell starts life with a signal ignored,
> that the shell should silently reject attempts to alter the fact
> that the signal is ignored (either back to a default, or to a
> user-specified handler). Which is very annoying if your shell ever
> gets started with SIGPIPE ignored, but that's life. In other words,
> if you start bash with SIGINT ignored, you can't undo that from
> within the bash shell.

OK, thanks for the explanations. So, the following script shows a bug
in zsh (typing Ctrl-C immediately interrupts the sleep and the script
and SIGINT is output):

#!/bin/sh

trap ''  INT
zsh -fc "emulate sh; trap 'echo SIGINT; exit' INT; sleep 6"

I wonder whether zsh should behave in the same way without
"emulate sh".

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

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

[Eric Blake]

Vincent Lefevre <vincent <at> vinc17.org> writes:

> 
> Sorry, I was not enough clear. I meant that bash restores the trap
> to the behavior at the time that bash was called. But it seems to
> be something different, something like if SIGINT is ignored when
> bash is executed, a "trap command INT" has no effect unless both
> bash and its child receive a SIGINT. Now, this behavior is a bit
> strange, maybe a bug.

POSIX requires that if a shell starts life with a signal ignored, that the shell
should silently reject attempts to alter the fact that the signal is ignored
(either back to a default, or to a user-specified handler).  Which is very
annoying if your shell ever gets started with SIGPIPE ignored, but that's life.
 In other words, if you start bash with SIGINT ignored, you can't undo that from
within the bash shell.

-- 
Eric Blake

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

[Vincent Lefevre]

On 2009-07-19 11:31:47 -0700, Bart Schaefer wrote:
> On Jul 19,  1:09am, Vincent Lefevre wrote:
> } Subject: Re: zsh 4.3.10 terminates with SIGINT when one types Ctrl-G in em
> }
> } > } [bash] 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?
> 
> If bash really "restores the trap to the default behavior, in case it was
> ignored" then I think bash is wrong because "the default behavior" is to
> exit on the signal.

Sorry, I was not enough clear. I meant that bash restores the trap
to the behavior at the time that bash was called. But it seems to
be something different, something like if SIGINT is ignored when
bash is executed, a "trap command INT" has no effect unless both
bash and its child receive a SIGINT. Now, this behavior is a bit
strange, maybe a bug.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

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

[Vincent Lefevre]

On 2009-07-19 09:32:31 -0700, Bart Schaefer wrote:
> On Jul 19, 11:51am, Vincent Lefevre wrote:
> }
> } In fact, it seems that zsh implements some form of WCE in
> } interactive scripts, whereas bash implements it in any case.
> 
> I think you'll find that if you "setopt restricted" you'll get yet
> another set of behaviors.

I don't find any difference.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

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

[Peter Stephenson]

Bart Schaefer wrote:
> On Jul 19, 12:15pm, Bart Schaefer wrote:
> }
> } The only way I can see to fix this is to re-introduce the wait_cmd second
> } argument to signal_suspend().  PWS?  Any thoughts?
> 
> Here's a patch in case there's agreement this is the right approach.

If it fixes both problems, it'll certainly do for now, until we work out
what it breaks.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

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

[Bart Schaefer]

On Jul 19, 12:15pm, Bart Schaefer wrote:
}
} The only way I can see to fix this is to re-introduce the wait_cmd second
} argument to signal_suspend().  PWS?  Any thoughts?

Here's a patch in case there's agreement this is the right approach.
Apply *instead of* zsh-workers/27165.  Line numbers may be wonky in
the jobs.c patch.

Index: Src/jobs.c
===================================================================
--- Src/jobs.c	17 Apr 2009 18:57:22 -0000	1.27
+++ Src/jobs.c	19 Jul 2009 19:19:10 -0000
@@ -1178,7 +1191,7 @@
 	    kill(pid, SIGCONT);
 
 	last_signal = -1;
-	signal_suspend(SIGCHLD);
+	signal_suspend(SIGCHLD, wait_cmd);
 	if (last_signal != SIGCHLD && wait_cmd && last_signal >= 0 &&
 	    (sigtrapped[last_signal] & ZSIG_TRAPPED)) {
 	    /* wait command interrupted, but no error: return */
@@ -1217,7 +1230,7 @@
 	while (!errflag && jn->stat &&
 	       !(jn->stat & STAT_DONE) &&
 	       !(interact && (jn->stat & STAT_STOPPED))) {
-	    signal_suspend(SIGCHLD);
+	    signal_suspend(SIGCHLD, wait_cmd);
 	    if (last_signal != SIGCHLD && wait_cmd && last_signal >= 0 &&
 		(sigtrapped[last_signal] & ZSIG_TRAPPED))
 	    {

Index: Src/signals.c
===================================================================
--- Src/signals.c	28 Feb 2009 07:13:37 -0000	1.22
+++ Src/signals.c	19 Jul 2009 20:07:04 -0000
@@ -342,29 +342,32 @@
 
 /**/
 int
-signal_suspend(UNUSED(int sig))
+signal_suspend(UNUSED(int sig), int wait_cmd)
 {
     int ret;
- 
-#ifdef POSIX_SIGNALS
+
+#if defined(POSIX_SIGNALS) || defined(BSD_SIGNALS)
     sigset_t set;
-#ifdef BROKEN_POSIX_SIGSUSPEND
+# if defined(POSIX_SIGNALS) && defined(BROKEN_POSIX_SIGSUSPEND)
     sigset_t oset;
-#endif /* BROKEN_POSIX_SIGSUSPEND */
+# endif
 
     sigemptyset(&set);
-#ifdef BROKEN_POSIX_SIGSUSPEND
+    if (!(wait_cmd || isset(TRAPSASYNC) ||
+	  (sigtrapped[SIGINT] & ~ZSIG_IGNORED)))
+	sigaddset(&set, SIGINT);
+#endif /* POSIX_SIGNALS || BSD_SIGNALS */
+
+#ifdef POSIX_SIGNALS
+# ifdef BROKEN_POSIX_SIGSUSPEND
     sigprocmask(SIG_SETMASK, &set, &oset);
     pause();
     sigprocmask(SIG_SETMASK, &oset, NULL);
-#else /* not BROKEN_POSIX_SIGSUSPEND */
+# else /* not BROKEN_POSIX_SIGSUSPEND */
     ret = sigsuspend(&set);
-#endif /* BROKEN_POSIX_SIGSUSPEND */
+# endif /* BROKEN_POSIX_SIGSUSPEND */
 #else /* not POSIX_SIGNALS */
 # ifdef BSD_SIGNALS
-    sigset_t set;
-
-    sigemptyset(&set);
     ret = sigpause(set);
 # else
 #  ifdef SYSV_SIGNALS

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

[Bart Schaefer]

On Jul 19, 11:03am, Bart Schaefer wrote:
}
} The following small change appears to restore the old behavior for SIGINT.

Unfortunately it does so too well.  It makes "wait" uninterruptible again,
which was the problem in the original thread at zsh-workers/23053.

The only way I can see to fix this is to re-introduce the wait_cmd second
argument to signal_suspend().  PWS?  Any thoughts?

} Hmm, looking at the #ifdef flow and considering that this affects MacOS,
} maybe the change in my patch needs to be in the BSD_SIGNALS section,
} either instead or as well.

I checked config.h on my iMac at work and it does not have BSD_SIGNALS,
so this isn't necessary for that reason, but it still might be a good
idea to have it in both branches.

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

[Bart Schaefer]

On Jul 19,  1:09am, Vincent Lefevre wrote:
} Subject: Re: zsh 4.3.10 terminates with SIGINT when one types Ctrl-G in em
}
} > } [bash] 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?

If bash really "restores the trap to the default behavior, in case it was
ignored" then I think bash is wrong because "the default behavior" is to
exit on the signal.  It should instead continue to ignore it, as requested
by the caller, as would have happened if the caller directly exec'd the
process instead of passing through bash along the way.

The patch I just sent for Src/signals.c sidesteps the issue in the way I
previously mentioned: without changing the eventual handling, it holds
SIGINT undelivered until some other signal interrupts signal_suspend().

Hmm, looking at the #ifdef flow and considering that this affects MacOS,
maybe the change in my patch needs to be in the BSD_SIGNALS section,
either instead or as well.

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

[Bart Schaefer]

On Jul 18, 11:16am, Bart Schaefer wrote:
}
} This was changed in this patch ...
} 
}         * 23067: Doc/Zsh/builtins.yo, Src/jobs.c, Src/signals.c:
}         queue traps but handle signals when waiting for jobs or processes,
}         unless TRAPSASYNC is set or the wait builtin is in use, so as
}         to handle untrapped signals in a timely fashion; document that
}         negative or zero process IDs after kill may be handled specially
}         by the OS.

The following small change appears to restore the old behavior for SIGINT.
The question is whether this should be applied to other signals that are
known to cause process termination, such as SIGQUIT.

I'm also not sure whether it's really necessary to test sigtrapped[], or
whether I've got the sense of that test right.

Index: Src/signals.c
===================================================================
diff -c -r1.22 signals.c
--- Src/signals.c	28 Feb 2009 07:13:37 -0000	1.22
+++ Src/signals.c	19 Jul 2009 17:52:28 -0000
@@ -353,6 +353,8 @@
 #endif /* BROKEN_POSIX_SIGSUSPEND */
 
     sigemptyset(&set);
+    if (!(isset(TRAPSASYNC) || (sigtrapped[SIGINT] & ~ZSIG_IGNORED)))
+	sigaddset(&set, SIGINT);
 #ifdef BROKEN_POSIX_SIGSUSPEND
     sigprocmask(SIG_SETMASK, &set, &oset);
     pause();


-- 

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

[Bart Schaefer]

On Jul 19, 11:51am, Vincent Lefevre wrote:
}
} In fact, it seems that zsh implements some form of WCE in
} interactive scripts, whereas bash implements it in any case.

I think you'll find that if you "setopt restricted" you'll get yet
another set of behaviors.

This really all comes down to what I said in zsh-workers/27159.

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

[Vincent Lefevre]

In fact, it seems that zsh implements some form of WCE in
interactive scripts, whereas bash implements it in any case.
Consider the following shell script:

sigint() { echo "SIGINT (sh)"; }
for i in 0 1 2 3
do
  trap - INT
  [ "$i" -eq 1 ] && trap sigint INT
  perl -e $i' or $SIG{"INT"} = sub { print "SIGINT (perl)\n" }; print "'$i' - $$\n"; sleep 30; $SIG{"INT"} = "DEFAULT"; kill "INT", $$'
done

Under Linux, whether this script is run in an interactive shell
or not (zsh or another one), I always get something like:

0 - 7387
^CSIGINT (perl)

and the script is immediately interrupted. Now, remove the

  $SIG{"INT"} = "DEFAULT"; kill "INT", $$

so that in the case i = 0, the Perl script is no longer killed
by SIGINT. Now, depending on the shell and how the script is
started, the script is interrupted either for i = 0 or i = 2
(the latter more of less corresponds to WCE, i.e. the sh script
is interrupted only if the Perl script is killed by SIGINT).

I considered the following two cases:
  1. "<shell> script.sh"
  2. ". script.sh" from the interactive shell

and I get the following results with:

  bash 3.2-5 (whether executed as bash or sh)
  dash 0.5.5.1-2
  ksh 93t+-2 (ksh93)
  pdksh 5.2.14-23
  posh 0.6.18
  zsh 4.3.10-3

under Debian/unstable.

* bash[1], dash[2], ksh93[1], pdksh[2], zsh[2]

0 - 7062
^CSIGINT (perl)
1 - 7063
^CSIGINT (sh)
2 - 7066
^C

* bash[2]

0 - 7241
^CSIGINT (perl)
1 - 7242
^C
2 - 7243
^C

* dash[1], ksh93[2], pdksh[1], posh[1], posh[2], zsh[1]

0 - 7387
^CSIGINT (perl)

Note that ksh93 does the opposite to pdksh and zsh!

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

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

[Vincent Lefevre]

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@vinc17.org> - 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)

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

[Bart Schaefer]

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.

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

[Bart Schaefer]

I'm going to send two replies to this part of the thread for different
subsets of Vincent's remarks, so that neither message gets too long.
This first one has a bunch of strace output in it.  Jump towards the
end for the punchline.

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:
} > When running a shell script (not interactively), zsh does NO HANDLING
} > of SIGINT whatsoever.  It's implementing IUE, not WUE.  Or to be more
} > precise, it's implementing the default behavior on SIGINT, which is
} > usually to exit.
} 
} Yes, this is what I can see with zsh 4.3.10 (but zsh 4.2.3 implemented
} WUE).

Let's look at that a bit more closely.

Here's 4.2.6 (slight difference in OS version may account for the
missing RT_1 in the sigprocmask):

pipe([3, 4])                            = 0
gettimeofday({1247938636, 336849}, {480, 0}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb75e4868) = 27231
close(4)                                = 0
read(3, "", 1)                          = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigsuspend(~[HUP CHLD RTMIN] <unfinished ...>
--- SIGCHLD (Child exited) @ 0 (0) ---
<... rt_sigsuspend resumed> )           = -1 EINTR (Interrupted system call)
rt_sigprocmask(SIG_BLOCK, ~[RTMIN], ~[HUP KILL STOP RTMIN], 8) = 0
rt_sigprocmask(SIG_SETMASK, ~[HUP KILL STOP RTMIN], ~[KILL STOP RTMIN], 8) = 0
wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], WNOHANG|WUNTRACED,
{ru_utime={0, 0}, ru_stime={0, 0}, ...}) = 27231
gettimeofday({1247938666, 347837}, {480, 0}) = 0
wait4(-1, 0xbfffd14c, WNOHANG|WUNTRACED, 0xbfffd154) = -1 ECHILD (No child
processes)
sigreturn()                             = ? (mask now [CHLD])
--- SIGINT (Interrupt) @ 0 (0) ---

Now here's 4.2.6 with the TRAPS_ASYNC option set:

pipe([3, 4])                            = 0
gettimeofday({1247939573, 896574}, {480, 0}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb75e0868) = 27252
close(4)                                = 0
read(3, "", 1)                          = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigsuspend([] <unfinished ...>
--- SIGINT (Interrupt) @ 0 (0) ---

And finally 4.3.10-dev-1, doesn't matter whether TRAPS_ASYNC is set:

pipe([3, 4])                            = 0
gettimeofday({1247938336, 854096}, {420, 0}) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD,
child_tidptr=0xb7f6c708) = 10263
close(4)                                = 0
read(3, "", 1)                          = 0
close(3)                                = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [CHLD], 8) = 0
rt_sigsuspend([] <unfinished ...>
--- SIGINT (Interrupt) @ 0 (0) ---

This was changed in this patch ...

        * 23067: Doc/Zsh/builtins.yo, Src/jobs.c, Src/signals.c:
        queue traps but handle signals when waiting for jobs or processes,
        unless TRAPSASYNC is set or the wait builtin is in use, so as
        to handle untrapped signals in a timely fashion; document that
        negative or zero process IDs after kill may be handled specially
        by the OS.

... when the signal_suspend_setup() function was removed from signals.c
because of a problem with interrupting "wait".  This began in 23053 as
a MacOS bug report and relevant dicussion continues in 23055 and 23061.

Apparently you darn Mac users can't make up your mind. :-)

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

[Vincent Lefevre]

On 2009-07-17 22:29:36 -0700, Bart Schaefer wrote:
> When running a shell script (not interactively), zsh does NO HANDLING
> of SIGINT whatsoever.  It's implementing IUE, not WUE.  Or to be more
> precise, it's implementing the default behavior on SIGINT, which is
> usually to exit.

Yes, this is what I can see with zsh 4.3.10 (but zsh 4.2.3 implemented
WUE).

> 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. Anyway, even though bash implements WCE,
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).

For instance, you can try with the following script with both bash
and zsh:

------------------------------------------------------------
echo "Caller: $$"
cmd="echo \"Callee: \$\$ ($SHELL)\"; sleep 6; echo OK"
trp="trap 'echo SIGINT; exit' INT; $cmd"

echo "Send SIGINT to each callee's PID"

$SHELL -c "$cmd"; echo "Callee's exit status: $?"
$SHELL -c "$trp"; echo "Callee's exit status: $?"

trap ''  INT
echo "SIGINT ignored"

$SHELL -c "$cmd"; echo "Callee's exit status: $?"
$SHELL -c "$trp"; echo "Callee's exit status: $?"

trap 'echo "Caller received SIGINT"'  INT
echo "Type Ctrl-C in the terminal"

$SHELL -c "$cmd"; echo "Callee's exit status: $?"
$SHELL -c "$trp"; echo "Callee's exit status: $?"
------------------------------------------------------------

Try also "killall -INT sleep" in the 6 cases.

> 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. If the caller
ignores SIGINT, then bash also ignores it. Moreover bash terminates
with exit status 130 only when it receives SIGINT and the child
terminates with exit status 130. (I've tried on a Linux machine with
bash 3.2 because I don't have access to my Mac OS X machine right
now.)

> 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?

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

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

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

[Bart Schaefer]

On Jul 16,  6:24pm, Vincent Lefevre wrote:
}
} Well, since bash implements WCE and is the default shell on Linux and
} Mac OS X machines, I'd say that such ill-behaved programs should not
} be common (and should be fixed). So, IMHO, there would be more benefit
} to have WCE in zsh.

So I investigated this a bit further and re-learned something I'd long
forgotten:

When running a shell script (not interactively), zsh does NO HANDLING
of SIGINT whatsoever.  It's implementing IUE, not WUE.  Or to be more
precise, it's implementing the default behavior on SIGINT, which is
usually to exit.

In reminding myself of this, I believe I've also remembered the reason
that it ended up this way, which leads to points of disagreement with
the analysis in http://www.cons.org/cracauer/sigint.html (source of
the IUE/WUE/WCE abbreviations).

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.

My recollection now, which may be wrong, is that there was a considerable
debate about this several years ago, leading to the decision to simply
stick with the default signal handling when the shell is not interactive,
for any signal that it isn't otherwise absolutely necessary to handle.

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.

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.

(2) Both the exiting and the waiting normally take place in zhandler()
when the signal in question arrives.  This means that to get the option
right, we have to record the state of both signals and then find a
common place guaranteed to be outside the race where we can examine
the combined state.

There might be enough state currently available in zhandler() to test
it on either signal and do the correct thing, but I'm not sure yet.

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

[Vincent Lefevre]

On 2009-07-13 19:39:24 +0100, Peter Stephenson wrote:
> Bart Schaefer wrote:
> > I'm not so sure.  You can emulate WCE with WUE and a trap,

I'll try to look at that.

> > but there is no way to make WCE do the right thing in the case of
> > an ill-behaved child that does not propagate the signal state
> > through exit status.

Well, since bash implements WCE and is the default shell on Linux and
Mac OS X machines, I'd say that such ill-behaved programs should not
be common (and should be fixed). So, IMHO, there would be more benefit
to have WCE in zsh.

> Could be an option (but I'm not writing it).

Yes, that would be nice, even though a trap emulating WCE could be as
simple (unless there are drawbacks).

In any case, I think that the behavior should be documented.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

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

[Peter Stephenson]

Bart Schaefer wrote:
> } I've searched on Google, and found the explanations of the various
> } behaviors:
> } 
> }   http://www.cons.org/cracauer/sigint.html
> } 
> } IMHO, zsh should implement WCE, just like bash.
> 
> I'm not so sure.  You can emulate WCE with WUE and a trap, but there is
> no way to make WCE do the right thing in the case of an ill-behaved
> child that does not propagate the signal state through exit status.

Could be an option (but I'm not writing it).

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

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

[Bart Schaefer]

On Jul 13,  2:43am, Vincent Lefevre wrote:
} 
} Why does zsh 4.3.10 behave differently?

Hmm.  There was a change to trap handling, but that should only matter
if LOCAL_TRAPS is set.  I also wanted there to have been some change
related to configure detecting restartable syscalls, but I can't find
anything in the ChangeLog about that.

IMO 4.3.10 has got it right and the older zsh et al. do not.

} I've searched on Google, and found the explanations of the various
} behaviors:
} 
}   http://www.cons.org/cracauer/sigint.html
} 
} IMHO, zsh should implement WCE, just like bash.

I'm not so sure.  You can emulate WCE with WUE and a trap, but there is
no way to make WCE do the right thing in the case of an ill-behaved
child that does not propagate the signal state through exit status.

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

[Vincent Lefevre]

On 2009-07-12 14:50:01 -0700, Bart Schaefer wrote:
> This must be happening because either (1) emacs resets the TTY intr
> character to ^G or (2) emacs is sending a SIGINT to the terminal pgrp
> when it sees ^G.  Experimenting with "trap 'stty -a' INT" seems to
> point to the latter, but the SIGINT only makes it through to zsh once
> (or at least the trap fires only on the first ^G).

With zsh 4.3.10, all of them: with the script

trap 'echo INT' INT
/usr/bin/emacs -Q -nw
echo OK

if I hit C-g 4 times, then C-x C-c to quit emacs, I get:

INT
INT
INT
INT
OK

when I run the script with zsh 4.3.10, but just

INT
OK

when I run the script with bash, ksh or zsh 4.2.3.
Why does zsh 4.3.10 behave differently?

> Either way, I think this is a problem with emacs rather than zsh.  Try
> replacing emacs with a command that doesn't do its own input handling
> ("sleep 10", perhaps) and then type the normal intr character (^C).
> Do you expect the script to exit on *that* SIGINT?  [It does.]

With bash, the script exits, even though it doesn't exit in the
case of Ctrl-g in Emacs.

I've searched on Google, and found the explanations of the various
behaviors:

  http://www.cons.org/cracauer/sigint.html

IMHO, zsh should implement WCE, just like bash.

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)

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

[Bart Schaefer]

On Jul 12, 10:59pm, Vincent Lefevre wrote:
}
} Consider a script with a line like
} 
}   /usr/bin/emacs -Q -nw
} 
} Run it with:
} 
}   zsh -f ./script
} 
} and type Ctrl-G in Emacs. Then zsh terminates with a SIGINT, killing
} Emacs at the same time.

This must be happening because either (1) emacs resets the TTY intr
character to ^G or (2) emacs is sending a SIGINT to the terminal pgrp
when it sees ^G.  Experimenting with "trap 'stty -a' INT" seems to
point to the latter, but the SIGINT only makes it through to zsh once
(or at least the trap fires only on the first ^G).

Either way, I think this is a problem with emacs rather than zsh.  Try
replacing emacs with a command that doesn't do its own input handling
("sleep 10", perhaps) and then type the normal intr character (^C).
Do you expect the script to exit on *that* SIGINT?  [It does.]

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

[Vincent Lefevre]

Hi,

I've found a problem with zsh 4.3.10 (and some previous versions, as
this bug has occurred for quite a long time, and I've identified it
only now). I could trigger it only under Mac OS X (version 10.4.11).

Consider a script with a line like

  /usr/bin/emacs -Q -nw

or

  /Applications/MacPorts/Emacs.app/Contents/MacOS/Emacs -Q -nw

(the problem doesn't depend on the version of emacs, e.g. 21 or 22).

Run it with:

  zsh -f ./script

and type Ctrl-G in Emacs. Then zsh terminates with a SIGINT, killing
Emacs at the same time.

This problem also occurs with ksh 1993-12-28 p, but not with bash.
With zsh 4.2.3, the SINGINT occurs only after Emacs terminates (e.g.
by quitting it with C-x C-c).

-- 
Vincent Lefèvre <vincent@vinc17.org> - 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)