From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9183 invoked from network); 18 Jul 2009 18:35:48 -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 18:35:48 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 60126 invoked from network); 18 Jul 2009 18:35:40 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 18 Jul 2009 18:35:40 -0000 Received: (qmail 24884 invoked by alias); 18 Jul 2009 18:35:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27161 Received: (qmail 24874 invoked from network); 18 Jul 2009 18:35:31 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 18 Jul 2009 18:35:31 -0000 Received: from vms173001pub.verizon.net (vms173001pub.verizon.net [206.46.173.1]) by bifrost.dotsrc.org (Postfix) with ESMTP id CC175801E289 for ; Sat, 18 Jul 2009 20:35:27 +0200 (CEST) Received: from torch.brasslantern.com ([96.238.220.32]) by vms173001.mailsrvcs.net (Sun Java(tm) System Messaging Server 6.3-7.04 (built Sep 26 2008; 32bit)) with ESMTPA id <0KMZ00JFAQANJ857@vms173001.mailsrvcs.net> for zsh-workers@sunsite.dk; Sat, 18 Jul 2009 13:35:16 -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 n6IIZAqw010407 for ; Sat, 18 Jul 2009 11:35:10 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id n6IIZ9lU010406 for zsh-workers@sunsite.dk; Sat, 18 Jul 2009 11:35:09 -0700 From: Bart Schaefer Message-id: <090718113509.ZM10405@torch.brasslantern.com> Date: Sat, 18 Jul 2009 11:35:09 -0700 In-reply-to: <20090718101602.GA5392@xvii> 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 18, 12:16pm) References: <090712193623.ZM14823@torch.brasslantern.com> <200907131839.n6DIdO6Z003291@pws-pc.ntlworld.com> <20090716162419.GA26179@prunille.vinc17.org> <090717222936.ZM8648@torch.brasslantern.com> <20090718101602.GA5392@xvii> 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/9588/Sat Jul 18 07:14:41 2009 on bifrost X-Virus-Status: Clean 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.