From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4716 invoked from network); 3 Aug 2008 11:29:02 -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; 3 Aug 2008 11:29:02 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 55760 invoked from network); 3 Aug 2008 11:28:57 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 3 Aug 2008 11:28:57 -0000 Received: (qmail 25484 invoked by alias); 3 Aug 2008 11:28:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25379 Received: (qmail 25465 invoked from network); 3 Aug 2008 11:28:43 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 3 Aug 2008 11:28:43 -0000 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.177]) by bifrost.dotsrc.org (Postfix) with ESMTP id 3682D80590E6 for ; Sun, 3 Aug 2008 13:28:39 +0200 (CEST) Received: by wa-out-1112.google.com with SMTP id v27so1304542wah.21 for ; Sun, 03 Aug 2008 04:28:37 -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=GluFPkdEMfi+VL+wqxVPQo1f9CG5wuFcZ11DaNbcDUI=; b=YjSy0f+Wcz4JmDz0q6VETNQclOHLhDSwrC9gdHgyienfiDhuSuo0+RUcAuXv/F6On4 37nfXml9R5eKSMEO03gSK7y3REiSMgCGd8WUzROrzUj2lPwx/eMdYWW2cOKOrqA8iwYv zDA1g8iR5bw0Q96PO/QOxg7ov6ylGeyrLrV/I= 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=b4fD/2s23V1pwsSuLoy1JWL2/MzEkd/zh9KNV4jvZfaysEOO8Sl7f0qAMVeKcDUZWF bDYGQhX4tHbUxIJEx/dej5GlAYI1YVGg5saHhrKr/WtmZVgx5TYnwRQI0JFj+FjVcPgQ XVBbZt7MAOcYfzxXIMaSAbuzQT70MSzznHKQE= Received: by 10.115.92.2 with SMTP id u2mr13519968wal.33.1217762917775; Sun, 03 Aug 2008 04:28:37 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Sun, 3 Aug 2008 04:28:37 -0700 (PDT) Message-ID: <6cd6de210808030428odaee1e6ja511305c6dd4ac46@mail.gmail.com> Date: Sun, 3 Aug 2008 07:28:37 -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: <20080803114215.219b616a@pws-pc> 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> <6cd6de210808020421k78d716a0mc995862eb761ea2@mail.gmail.com> <20080803114215.219b616a@pws-pc> X-Virus-Scanned: ClamAV 0.92.1/7920/Sun Aug 3 10:44:32 2008 on bifrost X-Virus-Status: Clean Comments in line. On Sun, Aug 3, 2008 at 6:42 AM, Peter Stephenson wrote: > On Sat, 2 Aug 2008 07:21:43 -0400 > "Rocky Bernstein" wrote: >> >> 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). > > This happens on any explicit "return" from a non-function trap. > >> It might also be nice to have a "trap DEBUG" exit value which >> indicates that the next command is skipped rather than executed. > > That's a little more tricky: it's not very clear what the next command > actually is if it's a complicated expression. Looking at the code, it's > not hard to do something here, but making it properly consistent is > another matter. I think it would probably work if done at the level of > commands separated by semicolons, newlines or ampersands (described > internally as sublists). I do not see why this is semantically complicated when the trap DEBUG occurs before the statement it refers to is run. Can you give a very specific example of something you feel is tricky? > >> And since I brought up "trap DEBUG" execution order again, at the risk >> of beating a dead horse... > > I don't really understand what the issue is. Is there something about > the DEBUG_BEFORE_CMD option that makes it hard to ensure it is set at > the right point (this is not a trick question, that's perfectly > possible)? David Korn made a mistake and he says so. Chet Ramey also says he changed the behavior because he thought it a mistake too. zsh copied the mistake. The only claim I've heard for keeping the mistake is compatibility with previous versions of zsh. However right now there is no evidence that anyone is making use of this mistake that would not be happier if it weren't made. When this mistake was corrected in bash and ksh, no complaint was registered to keep the old less-helpful behavior. Generally one thinks of the default value as the thing most people would choose. Compatibility is a good thing, but using it as an argument for keeping a mistake that no one is using, seems to me to be blindly following a rule without understanding why the rule is there. So the suggestion is changing the default behavior to something which follows both bash and ksh of the last 6 or so years. If nothing else, both bash and sh emulation in zsh should make this default behavior. Thanks.