From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23397 invoked from network); 15 Dec 2006 21:00:50 -0000 X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.5 required=5.0 tests=BAYES_00,FORGED_RCVD_HELO autolearn=ham version=3.1.7 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 15 Dec 2006 21:00:50 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 2295 invoked from network); 15 Dec 2006 21:00:43 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 15 Dec 2006 21:00:43 -0000 Received: (qmail 13373 invoked by alias); 15 Dec 2006 21:00:41 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23055 Received: (qmail 13363 invoked from network); 15 Dec 2006 21:00:40 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 15 Dec 2006 21:00:40 -0000 Received: (qmail 1957 invoked from network); 15 Dec 2006 21:00:40 -0000 Received: from mtaout03-winn.ispmail.ntl.com (81.103.221.49) by a.mx.sunsite.dk with SMTP; 15 Dec 2006 21:00:36 -0000 Received: from aamtaout02-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout03-winn.ispmail.ntl.com with ESMTP id <20061215210034.FVAI1865.mtaout03-winn.ispmail.ntl.com@aamtaout02-winn.ispmail.ntl.com> for ; Fri, 15 Dec 2006 21:00:34 +0000 Received: from pwslaptop.csr.com ([82.6.97.117]) by aamtaout02-winn.ispmail.ntl.com with ESMTP id <20061215210034.GIPB17393.aamtaout02-winn.ispmail.ntl.com@pwslaptop.csr.com> for ; Fri, 15 Dec 2006 21:00:34 +0000 Received: from pwslaptop.csr.com (pwslaptop.csr.com [127.0.0.1]) by pwslaptop.csr.com (8.13.8/8.13.7) with ESMTP id kBFL0OTC003197 for ; Fri, 15 Dec 2006 21:00:25 GMT Message-Id: <200612152100.kBFL0OTC003197@pwslaptop.csr.com> From: Peter Stephenson To: Zsh hackers list Subject: Re: Is wait not interruptable? In-Reply-To: Message from Peter Stephenson of "Fri, 15 Dec 2006 12:05:57 GMT." <20061215120557.dc06f65b.pws@csr.com> Date: Fri, 15 Dec 2006 21:00:24 +0000 Peter Stephenson wrote: > The first is that the subshell itself (the stuff in parentheses) doesn't > get killed because it's waiting for the child process. This seems to be a > feature of SIGTERM. If you "setopt trapsasync" or send a different signal > such as SIGHUP it does get killed. I'm not really sure why SIGTERM is > different. I got a chance to look at the code in more detail. It's not SIGTERM that's different, it's SIGHUP. The code is: if (isset(TRAPSASYNC)) { sigemptyset(set); } else { sigfillset(set); sigdelset(set, sig); #ifdef POSIX_SIGNALS sigdelset(set, SIGHUP); /* still don't know why we add this? */ #endif if (wait_cmd) { /* * Using "wait" builtin. We should allow SIGINT and * execute traps delivered to the shell. */ int sigtr; sigdelset(set, SIGINT); for (sigtr = 1; sigtr <= NSIG; sigtr++) { if (sigtrapped[sigtr] & ~ZSIG_IGNORED) sigdelset(set, sigtr); } } } So there's not really any mystery about how it behaves, only why it's the way it is. POSIX is fairly light on what to do with signals: http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_11 TRAPSASYNC was really introduced, as the name suggests, to affect trap execution (see second paragraph of the section in the URL), not the point at which the signal is delivered to the shell, but in practice it does the former by altering the latter. The may be a case for always handling the signal immediately and altering the code only to delay any traps. But I'm still not sure why it's done the way it is. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/