From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6477 invoked from network); 1 Aug 2008 15:32:26 -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.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 1 Aug 2008 15:32:26 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 10138 invoked from network); 1 Aug 2008 15:32:21 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 1 Aug 2008 15:32:21 -0000 Received: (qmail 22236 invoked by alias); 1 Aug 2008 15:32:06 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25369 Received: (qmail 22189 invoked from network); 1 Aug 2008 15:32:00 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 1 Aug 2008 15:32:00 -0000 Received: from cluster-g.mailcontrol.com (cluster-g.mailcontrol.com [208.87.233.190]) by bifrost.dotsrc.org (Postfix) with ESMTPS id 183B6805A42E for ; Fri, 1 Aug 2008 17:31:53 +0200 (CEST) Received: from rly27g.srv.mailcontrol.com (localhost.localdomain [127.0.0.1]) by rly27g.srv.mailcontrol.com (MailControl) with ESMTP id m71FVkEU001512 for ; Fri, 1 Aug 2008 16:31:46 +0100 Received: from submission.mailcontrol.com (submission.mailcontrol.com [86.111.216.190]) by rly27g.srv.mailcontrol.com (MailControl) id m71FVL1h030131 for zsh-workers@sunsite.dk; Fri, 1 Aug 2008 16:31:21 +0100 Received: from cameurexb01.EUROPE.ROOT.PRI ([193.128.72.68]) by rly27g-eth0.srv.mailcontrol.com (envelope-sender Peter.Stephenson@csr.com) (MIMEDefang) with ESMTP id m71FVI9P029792; Fri, 01 Aug 2008 16:31:21 +0100 (BST) Received: from news01.csr.com ([10.103.143.38]) by cameurexb01.EUROPE.ROOT.PRI with Microsoft SMTPSVC(6.0.3790.3959); Fri, 1 Aug 2008 16:31:18 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.14.2/8.13.4) with ESMTP id m71FVIep028549; Fri, 1 Aug 2008 16:31:18 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.14.2/8.14.2/Submit) with ESMTP id m71FVIFl028545; Fri, 1 Aug 2008 16:31:18 +0100 Message-Id: <200808011531.m71FVIFl028545@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: "Rocky Bernstein" cc: zsh-workers@sunsite.dk Subject: Re: Weird exit caused in a trap DEBUG which sources a file. In-reply-to: <6cd6de210808010821g3117fe62y82bd580811dbba8a@mail.gmail.com> References: <6cd6de210807301938m28e05c84vf6296aa5b1bc0d44@mail.gmail.com> <200807310901.m6V91g8T002478@news01.csr.com> <6cd6de210807310305q5954b65ax405f51e54d6754ee@mail.gmail.com> <6cd6de210808010529h11898619kba301fddf8b72f00@mail.gmail.com> <20080801143747.19b65086@news01> <6cd6de210808010821g3117fe62y82bd580811dbba8a@mail.gmail.com> Comments: In-reply-to "Rocky Bernstein" message dated "Fri, 01 Aug 2008 11:21:50 -0400." Date: Fri, 01 Aug 2008 16:31:18 +0100 From: Peter Stephenson X-OriginalArrivalTime: 01 Aug 2008 15:31:18.0124 (UTC) FILETIME=[A46892C0:01C8F3EB] X-Scanned-By: MailControl A-08-50-03 (www.mailcontrol.com) on 10.71.1.137 X-Virus-Scanned: ClamAV 0.92.1/7911/Fri Aug 1 14:10:36 2008 on bifrost X-Virus-Status: Clean "Rocky Bernstein" wrote: > On Fri, Aug 1, 2008 at 9:37 AM, Peter Stephenson wrote: > > Thanks, this is what I needed. > > No, thank you! I just tried the patch and it works fine. Good. > So there's no mystery. I've been porting the bash debugger code to > zsh. So far, print/eval, stepping and some stack frame commands work. > But this is far from ready for general consumption. This will be very useful. > > The signals.c hunk is to save and restore trapreturn for nested trap > > handlers. I'm not sure it's necessary; I am sure it's not wrong and > > prevents hostages to fortune. > > Not sure the additional code is necessary or that nested trap handlers > are necessary? I'm pretty sure you mean the former. Nested trap > handlers are useful. Yes, I'm talking about the additional code. I think it probably *is* necessary for consistency, but there are cases where we disable nested handling (so for example we don't run a DEBUG trap on commands when we're inside a DEBUG trap). > It seems weird that trapreturn is is initialised to -1 for a > function trap and > -2 for a non-function trap and decremented for subsequent function > calls. Because this means that trapreturn for a for a function trap > that calls a function would have the same value as for a non-function > trap. This is because of the way an explicit "return" from a trap works (which is documented in the manual). "return" with non-zero status from a shell function forces the parent function to return; "return" with any status from a non-function trap forces the immediately surrounding function to return. In other words, the difference is there's an extra level of functions in one case which we have to jump over for the special return. -- Peter Stephenson Software Engineer CSR PLC, Churchill House, Cambridge Business Park, Cowley Road Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070