From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16770 invoked from network); 7 Aug 2008 14:53:35 -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=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; 7 Aug 2008 14:53:35 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 95147 invoked from network); 7 Aug 2008 14:53:21 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 7 Aug 2008 14:53:21 -0000 Received: (qmail 9451 invoked by alias); 7 Aug 2008 14:53:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25420 Received: (qmail 9431 invoked from network); 7 Aug 2008 14:53:05 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 7 Aug 2008 14:53:05 -0000 Received: from vms044pub.verizon.net (vms044pub.verizon.net [206.46.252.44]) by bifrost.dotsrc.org (Postfix) with ESMTP id 82B25808A1CD for ; Thu, 7 Aug 2008 16:52:59 +0200 (CEST) Received: from torch.brasslantern.com ([96.238.220.37]) by vms044.mailsrvcs.net (Sun Java System Messaging Server 6.2-6.01 (built Apr 3 2006)) with ESMTPA id <0K58009R2K04DPN5@vms044.mailsrvcs.net> for zsh-workers@sunsite.dk; Thu, 07 Aug 2008 09:52:54 -0500 (CDT) Received: from torch.brasslantern.com (localhost.localdomain [127.0.0.1]) by torch.brasslantern.com (8.13.1/8.13.1) with ESMTP id m77Eqq67017287 for ; Thu, 07 Aug 2008 07:52:52 -0700 Received: (from schaefer@localhost) by torch.brasslantern.com (8.13.1/8.13.1/Submit) id m77EqpXZ017286 for zsh-workers@sunsite.dk; Thu, 07 Aug 2008 07:52:51 -0700 Date: Thu, 07 Aug 2008 07:52:51 -0700 From: Bart Schaefer Subject: Re: PATCH: skip command from debug trap In-reply-to: <20080807111122.3325ada0@news01> To: Zsh hackers list Message-id: <080807075251.ZM17285@torch.brasslantern.com> MIME-version: 1.0 X-Mailer: OpenZMail Classic (0.9.2 24April2005) Content-type: text/plain; charset=us-ascii References: <27237.1217946438@csr.com> <6cd6de210808051647k17f14902nce840ca3edd6ddb@mail.gmail.com> <20080806104716.44647a75@news01> <080806072236.ZM14655@torch.brasslantern.com> <6cd6de210808060730q3ebdc5cdt71b381f861ff0fa1@mail.gmail.com> <20080806145917.GE5197@sc.homeunix.net> <20080806163410.0ce3cacd@news01> <6cd6de210808061000l5c6e0a8fheb06db75560a1598@mail.gmail.com> <200808061754.m76HsOQv002657@news01.csr.com> <6cd6de210808061209g30b82612r148e576dbe1941bd@mail.gmail.com> <200808061949.m76Jn10k020995@pws-pc.ntlworld.com> <080806180010.ZM15414@torch.brasslantern.com> <20080807111122.3325ada0@news01> Comments: In reply to Peter Stephenson "Re: PATCH: skip command from debug trap" (Aug 7, 11:11am) X-Virus-Scanned: ClamAV 0.92.1/7972/Thu Aug 7 14:22:20 2008 on bifrost X-Virus-Status: Clean On Aug 7, 11:11am, Peter Stephenson wrote: } Subject: Re: PATCH: skip command from debug trap } } On Wed, 06 Aug 2008 18:00:10 -0700 } Bart Schaefer wrote: } > } > TRAPDEBUG() { return 1 } } > setopt DEBUG_BEFORE_CMD IGNORE_EOF } > } > You've just rendered your shell useless. You can't even exit from it } > (except by way of the ten-EOFs failsafe we put in some while ago). } } I suppose that's power vs. responsibility. One point: This becomes even easier to screw up if DEBUG_BEFORE_CMD is the default behavior, and would be mystifying to a typical user. } > I propose that ERR_EXIT be unset on entry to TRAPDEBUG, always. Then at } > return from the function, if ERR_EXIT has become set, treat that as an } > indication to skip the command (and restore ERR_EXIT to whatever its } > pre-function state was). After sending this I thought "hmm, I could just as easily have suggested a new option." I guess it's a good thing I didn't. } > If you setopt ERR_EXIT and return non-zero } > you still get what you always would (anyway, if you really wanted the } > shell to exit, you can just call "exit" from the trap). } } This seems quite neat, it even gets round the nastiness of working out } which level of the function call stack your at to fiddle with the return } value. It seems perfectly reasonable to make non-use of ERR_EXIT within } DEBUG traps a documented feature: we already do this during initialisation } scripts and can invoke the same mechanism trivially here. That's not quite } what you said---you said let it behave as normal but with the additional } feature, but given we have the other mechanism to suppress its use, it } seems neater to apply that here when hijacking the option, right? Yes; in fact when I first wrote it down I suggested exactly that, but then noticed that it wasn't necessary to disable it entirely and backed out that part. If it's actually *easier* this way, the "you can just call 'exit'" still applies.