From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8652 invoked from network); 26 Apr 2005 00:53:03 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 26 Apr 2005 00:53:03 -0000 Received: (qmail 75256 invoked from network); 26 Apr 2005 00:52:53 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 26 Apr 2005 00:52:53 -0000 Received: (qmail 17372 invoked by alias); 26 Apr 2005 00:52:43 -0000 Mailing-List: contact zsh-users-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 8757 Received: (qmail 17358 invoked from network); 26 Apr 2005 00:52:42 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 26 Apr 2005 00:52:42 -0000 Received: (qmail 73869 invoked from network); 26 Apr 2005 00:52:42 -0000 Received: from lakermmtao04.cox.net (68.230.240.35) by a.mx.sunsite.dk with SMTP; 26 Apr 2005 00:52:37 -0000 Received: from quark.hightek.org ([68.12.75.33]) by lakermmtao04.cox.net (InterMail vM.6.01.04.00 201-2131-118-20041027) with ESMTP id <20050426005233.XDQS20878.lakermmtao04.cox.net@quark.hightek.org> for ; Mon, 25 Apr 2005 20:52:33 -0400 Received: by quark.hightek.org (Postfix, from userid 501) id 95D944588C; Mon, 25 Apr 2005 19:50:59 -0500 (CDT) Date: Mon, 25 Apr 2005 19:50:59 -0500 From: Vincent Stemen To: zsh-users@sunsite.dk Subject: Re: localtraps Message-ID: <20050426005059.GA20665@quark.hightek.org> References: <20050425063521.GA17598@quark.hightek.org> <1050425163202.ZM25027@candle.brasslantern.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1050425163202.ZM25027@candle.brasslantern.com> User-Agent: Mutt/1.4.1i X-Spam-Checker-Version: SpamAssassin 3.0.2 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, score=-2.6 required=6.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Hits: -2.6 On Mon, Apr 25, 2005 at 04:32:02PM +0000, Bart Schaefer wrote: > On Apr 25, 1:35am, Vincent Stemen wrote: > } Subject: localtraps > } > } I don't seem to be able to get the localtraps option to work. > > Try it where the outer function is NOT a trap for the same signal > that you're trapping inside the function. > > I suspect that changing the trap of the same signal that is trapped > is confusing the trap code, because low-level signal handling already > requires that the signal handler restore itself before exiting, so in > effect you're restoring multiple different traps, and the order in > which function exit and trap unwinding are processed is mixed up. Thanks for the response. Yes, You are correct. I tested trapping a different signal in the signal trap function and the localtraps option did indeed work. I got the same result on zsh 4.2.0 (i386-unknown-freebsd5.2.1) and zsh 4.0.7 (i386-redhat-linux-gnu) (Except I had to re-write my test function to not run any additional utilities such as sleep in order to properly test it on Linux because of Linux's dumb signal handling. It does not pass signals on to the parent process like BSD does.) On both, if I try to change the trap for the same signal in the trap handler function with localtraps on, it ignores the new trap. However, As I mentioned earlier, I get a different behavior on zsh 4.2.1 (i386--netbsdelf) It resets the signal trap, rather than ignoring it, but ignores the localtraps option so that the new trap is still in effect after exiting the function. It seems to me that either behavior should be considered a bug in zsh. This renders the localtraps option not useful to me much of the time because I often need to temporarily disable or modify the function of the same signal while I am in the signal handler processing it. Is this an architectural problem with zsh that would be difficult to fix? To make it easier for anybody that wants to test it, here is my re-written and improved test script that generates it's own signals. #--------------------------------------------- #!/bin/zsh sigterm1() { setopt LOCAL_TRAPS trap sigterm2 TERM echo "sigterm1(): sending SIGTERM" kill -s TERM $$ } sigterm2() { echo "sigterm2()" } trap sigterm1 TERM echo echo "main: sending SIGTERM" kill -s TERM $$ echo "main: sending SIGTERM" kill -s TERM $$ echo #--------------------------------------------- On the versions I mentioned above on Linux and FreeBSD this will go into an endless loop printing "sigterm1(): sending SIGTERM" because the trap statement in sigterm1() is ignored, unless you comment out "setopt LOCAL_TRAPS". -- Vincent Stemen Avoid the VeriSign/Network Solutions domain registration trap! Read how Network Solutions (NSI) was involved in stealing our domain name. http://www.InetAddresses.net