From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19759 invoked from network); 2 Aug 2008 11:22:37 -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; 2 Aug 2008 11:22:37 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 40258 invoked from network); 2 Aug 2008 11:22:14 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 2 Aug 2008 11:22:14 -0000 Received: (qmail 21486 invoked by alias); 2 Aug 2008 11:22:04 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25371 Received: (qmail 21459 invoked from network); 2 Aug 2008 11:22:01 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 2 Aug 2008 11:22:01 -0000 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.180]) by bifrost.dotsrc.org (Postfix) with ESMTP id ECF06805A42E for ; Sat, 2 Aug 2008 13:21:44 +0200 (CEST) Received: by wa-out-1112.google.com with SMTP id v27so1046730wah.21 for ; Sat, 02 Aug 2008 04:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SmowmT5ommdq7CrxzgJO/93S8LpOysFQ8MdLB90J/vg=; b=g/EI8WKDzZapdNcEjS7zBKfEGaRLtqsaIf7xZXIC5dWOQROIbxYAHwhKyOPPEkT+qK TCTACGwdsUC2ZGnRG0LTsWbsgloKmxP4o9CfgxF+krU3ToTVhLDIqjLqDc/tbJVlJR31 zi13MsFr+ZaoE/6UU/ebtvnab6y978RvVFpIQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=SZ9cuqh9f3m4RoeMQON9Win48vPlQ9cBIVRgPWsVRcueV5ud2dR3oihqKgZaIgkbfK L2vy3UxXWx7sdkc92/DrHHpFkg55f/xJB/tunXOElMikVnAENTjkRcYd0AFHKTnbS2+f qIoY/6Dny6i5x7LmWRtePxea7pke/xj7LiE9M= Received: by 10.115.76.5 with SMTP id d5mr12709917wal.191.1217676103401; Sat, 02 Aug 2008 04:21:43 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Sat, 2 Aug 2008 04:21:43 -0700 (PDT) Message-ID: <6cd6de210808020421k78d716a0mc995862eb761ea2@mail.gmail.com> Date: Sat, 2 Aug 2008 07:21:43 -0400 From: "Rocky Bernstein" To: zsh-workers@sunsite.dk Subject: Re: Weird exit caused in a trap DEBUG which sources a file. In-Reply-To: <200808011531.m71FVIFl028545@news01.csr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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> <200808011531.m71FVIFl028545@news01.csr.com> X-Virus-Scanned: ClamAV 0.92.1/7915/Sat Aug 2 05:45:09 2008 on bifrost X-Virus-Status: Clean Hmm. This brings up a couple of other things to consider. It may be useful to have some "trap DEBUG" exit codes alter program flow. For example in bash if "trap DEBUG" returns 2, then if you are inside a function that does an immediate return from the function (implementing a gdb "return" command). It might also be nice to have a "trap DEBUG" exit value which indicates that the next command is skipped rather than executed. Of course, this makes more sense when "trap DEBUG" is run before a statement is executed rather than after, because doing these things when you don't really know what the next statement is or which function you are in is like flying blind. And since I brought up "trap DEBUG" execution order again, at the risk of beating a dead horse... I recently asked David Korn about this: me: I guess what I was asking is why it originally kicked in afterwards rather than before. This one seemingly innocuous thing is one of the biggest things that kept writing a serious debugger impossible. (But of course as perhaps you may understand, there are others that still make it hard.) David Korn: That was a mistake which is why I changed it. I also recall suggesting to Chet Ramey that another trap could be added like "trap DEBUG" if compatibility was at issue. Although I never got a reply, he too didn't try to keep the previous behavior which suggests, like David Korn, he thought it just wrong. In neither case am I aware of any outcry of incompatibility because this behavior was changed. On Fri, Aug 1, 2008 at 11:31 AM, Peter Stephenson wrote: > > 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 >