From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19902 invoked from network); 18 Jul 2009 05:30:15 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from new-brage.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.254.104) by ns1.primenet.com.au with SMTP; 18 Jul 2009 05:30:15 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 46463 invoked from network); 18 Jul 2009 05:30:06 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Jul 2009 05:30:06 -0000 Received: (qmail 18514 invoked by alias); 18 Jul 2009 05:29:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27157 Received: (qmail 18495 invoked from network); 18 Jul 2009 05:29:56 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 18 Jul 2009 05:29:56 -0000 Received: from vms173003pub.verizon.net (vms173003pub.verizon.net [206.46.173.3]) by bifrost.dotsrc.org (Postfix) with ESMTP id 04DDA8027106 for ; Sat, 18 Jul 2009 07:29:50 +0200 (CEST) Received: from torch.brasslantern.com ([96.238.220.32]) by vms173003.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KMY008CAPXEG6C4@vms173003.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 18 Jul 2009 00:29:39 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id n6I5TaqV008650 for ; Fri, 17 Jul 2009 22:29:37 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n6I5TaUI008649 for zsh-workers@sunsite.dk; Fri, 17 Jul 2009 22:29:36 -0700 From: Bart Schaefer Message-id: <090717222936.ZM8648@torch.brasslantern.com> Date: Fri, 17 Jul 2009 22:29:36 -0700 In-reply-to: <20090716162419.GA26179@prunille.vinc17.org> Comments: In reply to Vincent Lefevre "Re: zsh 4.3.10 terminates with SIGINT when one types Ctrl-G in emacs under Mac OS X" (Jul 16, 6:24pm) References: <090712193623.ZM14823@torch.brasslantern.com> <200907131839.n6DIdO6Z003291@pws-pc.ntlworld.com> <20090716162419.GA26179@prunille.vinc17.org> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@sunsite.dk Subject: Re: zsh 4.3.10 terminates with SIGINT when one types Ctrl-G in emacs under Mac OS X MIME-version: 1.0 Content-type: text/plain; charset=us-ascii X-Virus-Scanned: ClamAV 0.94.2/9587/Sat Jul 18 06:25:22 2009 on bifrost X-Virus-Status: Clean 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.