From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21488 invoked from network); 5 Aug 2008 11:19:04 -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; 5 Aug 2008 11:19:04 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 71219 invoked from network); 5 Aug 2008 11:18:47 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 5 Aug 2008 11:18:47 -0000 Received: (qmail 20187 invoked by alias); 5 Aug 2008 11:18:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25395 Received: (qmail 20156 invoked from network); 5 Aug 2008 11:18:26 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 5 Aug 2008 11:18:26 -0000 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.178]) by bifrost.dotsrc.org (Postfix) with ESMTP id E7E1E80590E6 for ; Tue, 5 Aug 2008 13:18:09 +0200 (CEST) Received: by wa-out-1112.google.com with SMTP id v27so1956143wah.21 for ; Tue, 05 Aug 2008 04:18:08 -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=5R4VUilvl3n0IYIfh0TsQkfPmN9CKKf59lK1/+nG4qs=; b=rHc/Bl4wDq5yo1rlrfGohpoOWh1i5Hg2KZfymqwVLrj/nvhJAk1CT7hYV1+3k6orgo g9k+PR9ij99G9Gf8ceYUlhcdcwQ6VsLohn8dNXYzSYCaSYYwZjohIa7gNuKw+OeOzhmD uaLkbamk0OjH7FAYoQtHQ8hY4Iil75dmDaKYQ= 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=bjdrAoVrKp12Yk/LSA3iCIwk43LfpiQJLAQdld+FjaXyyr08qY3SyZRW0NzS32eXbp Ygbu4Cx8v2wniWLVn+yp+uuXnNaB/uv4sXOs4RbmRc59wulzikbLjEup7aVTQuYfmSFS fSiWEc3CXyfJQECI/GWV+5ia5s3Cnac0Ym3f0= Received: by 10.114.183.20 with SMTP id g20mr15345725waf.77.1217935087725; Tue, 05 Aug 2008 04:18:07 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Tue, 5 Aug 2008 04:18:06 -0700 (PDT) Message-ID: <6cd6de210808050418u22aa3654mcdf7a833a868e782@mail.gmail.com> Date: Tue, 5 Aug 2008 07:18:06 -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: <20080803125033.4f9a7565@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> <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> <6cd6de210808030428odaee1e6ja511305c6dd4ac46@mail.gmail.com> <20080803125033.4f9a7565@pws-pc> X-Virus-Scanned: ClamAV 0.92.1/7941/Tue Aug 5 00:44:27 2008 on bifrost X-Virus-Status: Clean On Sun, Aug 3, 2008 at 7:50 AM, Peter Stephenson wrote: > On Sun, 3 Aug 2008 07:28:37 -0400 > "Rocky Bernstein" wrote: >> 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? > > You mean that the new return value from a DEBUG trap should skip > everything that would happen until the next trap is run? Yes. > That's kind of > what I ended up saying, and that's well-defined. Ok. I misunderstood. My mistake. I misremembered bash. The way it currently works is that a return code 1 from a trap causes a skip. See http://bashdb.sourceforge.net/bashdb.html#SEC36 for a description of the debugger command. Right now in bash returning 2 means immediate return. However, it might be slick to have a negative value skip that many levels of return. For a debugger this isn't strictly necessary because the debugger can keep track of the number of levels to return. However for those who write small custom trap DEBUG code (which right now is probably anyone who uses it) it can be a nice convenience. > >> 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. > > Well, there's no actual evidence it won't cause the toppling of > governments in small Himalayan kingdoms, either. We probably won't find > out unless we change the default. I agree setting DEBUG_BEFORE_CMD is > generally more useful, but you're the only user of the feature I've > heard from at all, and I still don't know if there's anything that makes > it hard to set the feature explicitly, in either direction (and at least > trying to set it in your script is the only way to guarantee the correct > behaviour). Well of course right now I do that, because I have to. :-) As for ensuring correct behavior, because the of the dearth of bugs, clearly I'll have to put some tests in to make sure features and bug fixes are there. I've been through this before. I probably won't explicitly test for trap DEBUG but rather may check $ZSH_VERSION. >>From my side it would be nice if the debuggers in bash, ksh and zsh shared the same code. But I agree all of this is small stuff. > > If you're going to produce a working debugger that requires this to be > set then I'll be very tempted to change the default, since a generally > available working debugger is extremely useful. There are lots of other useful changes I see happening so if I have a limit, I'd probably want to save that for some of the other things. Probably the next thing on the list is a way to get subshell levels. SHLVL check zsh/bash invocations, but one would like the same thing for subshells. (In bash it is called $BASH_SUBSHELL) I suspect this is pretty straightforward to do. Instead my argument was based on the fact that it's the Right Thing To Do (tm). There are a number of little benefits one gets by doing the right thing. Above I gave one small example. Here are some other small examples: Consider this thread on "How to debug a running process" http://groups.google.com/group/comp.unix.shell/browse_thread/thread/87c3f728476ed29d/5e056069f30efa35 which was written before I was aware of the current zsh behavior. Someone who reads that and decides to do follow will have to know and remember to set the ZSH-specific option to be more useful. RIght now I'm in early stages of writing a book which covers program development in POSIX shell. It will cover trap DEBUG, but I suppose I'd also have to mention the ZSH specific option. Do we want people reminded that this mistake was made and that ZSH makes its presence known by still setting doing this in a less helpful way? "trap DEBUG" is not currently mandated in POSIX 1003.1. However David Korn has said that a number of the features that are common in the POSIX-compatible shells should eventually find their way into some more aggressive spec. Making zsh like bash and ksh will only serve to increase the likelihood that when this happens, trap DEBUG will be there and done in the right way. > > Any definite views from anyone else are welcome. > As before with bash and ksh, resounding silence against and one or two people who've weighed in and said it seems like a good thing. I think it safe to say this is analogous to making the mistake 0/0=1. Many people won't notice or care or feel that strongly about. Personally having been annoyed 3 times by it, so it is irksome to me. Something like 8 years ago, I mentioned it to David Korn and he quickly acknowledged and changed it. Ok. I'll stop and I'll try to resist from written any more. Far more has been written about this than the possibly 1 character change to set this correctly. And by the way, if the current default is kept, it probably needs to be set it when "emulate sh" or "emulate bash" is in effect.