From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18918 invoked from network); 6 Aug 2008 19:09: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=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; 6 Aug 2008 19:09:37 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 29979 invoked from network); 6 Aug 2008 19:09:24 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 6 Aug 2008 19:09:24 -0000 Received: (qmail 25925 invoked by alias); 6 Aug 2008 19:09:13 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25408 Received: (qmail 25905 invoked from network); 6 Aug 2008 19:09:11 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 6 Aug 2008 19:09:11 -0000 Received: from yw-out-2324.google.com (yw-out-2324.google.com [74.125.46.29]) by bifrost.dotsrc.org (Postfix) with ESMTP id D92278056E06 for ; Wed, 6 Aug 2008 21:09:06 +0200 (CEST) Received: by yw-out-2324.google.com with SMTP id 5so30755ywb.81 for ; Wed, 06 Aug 2008 12:09:05 -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:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1MUOTx4EmfXl6kDRmXK/0mGYTNq6Ce3QBCSWyZXB1z0=; b=pk+mWvLxkJ23l6SX9dI9AEDHBre8YN/7OepfsPOFaZqThEFs/bPcK4OaEkAKsySAni g94wr/USYZgOg/5gXzuDgF8vWbYy5QaR7Gyyk6e4bDdOtdGs7HvXuTgRZm22y0K1LFsk h3qoGX25y+8iHV8SfNA+HcKBE+zVrjvPDYu2M= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=RMutgjYzBBiedqm0ujD8bv+cMft8cvYMhm6PkQZqrmYNVhT9cwvXmRIv8ELJ6oN7Hx QBHOW31UjM6m4V6OHJ62FQobJaFcuSFbVfU0D6OHba5y7tjFfAt6pIvn0V5pKs9b5VCj ad7V2JA77TpxuEf7ckmQ8B76ombr6n03NhjPc= Received: by 10.115.73.20 with SMTP id a20mr790945wal.32.1218049744686; Wed, 06 Aug 2008 12:09:04 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Wed, 6 Aug 2008 12:09:04 -0700 (PDT) Message-ID: <6cd6de210808061209g30b82612r148e576dbe1941bd@mail.gmail.com> Date: Wed, 6 Aug 2008 15:09:04 -0400 From: "Rocky Bernstein" To: "Peter Stephenson" Subject: Re: PATCH: skip command from debug trap Cc: "Zsh hackers list" In-Reply-To: <200808061754.m76HsOQv002657@news01.csr.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <27237.1217946438@csr.com> <6cd6de210808051647k17f14902nce840ca3edd6ddb@mail.gmail.com> <20080806104716.44647a75@news01> <6cd6de210808061000l5c6e0a8fheb06db75560a1598@mail.gmail.com> <200808061754.m76HsOQv002657@news01.csr.com> X-Virus-Scanned: ClamAV 0.92.1/7959/Wed Aug 6 15:06:37 2008 on bifrost X-Virus-Status: Clean On Wed, Aug 6, 2008 at 1:54 PM, Peter Stephenson wrote: > "Rocky Bernstein" wrote: >> Others have noted the challenges in adding an option to return. Making >> the semantics of the return statement already more complicated doesn't >> seem wise. > > However, as I've pointed out I can guarantee to make that compatible > with the current shell, and at the same time make return work as in > other shells (apart from the math eval of the numeric argument, which > would cause an error in other shells anyway) which it doesn't at the > moment. Once we have the latter adding an option is trivial. Adding an > option to a builtin is about the simplest thing it's possible to do. Ok. Adding an option to the return builtin is simple, even if there is no other shell that I know of that currently does this. But given the choice of adding 1) an option in the return statement everywhere that is specific to just "trap DEBUG" or 2) specifying what specific numbers do when on a return from "trap DEBUG", isn't 2) simpler and more consistent with programming in shell languages work? I take it as a given that every function or command is going to have error codes that are somewhat arbitrary and that I'm not going to intuit. For example POSIX 1003.1 specifies that grep returns 1 when no lines were selected and greater than 1 if there was an error, and for xargs it says return code 126 means "The utility specified by *utility* was found but could not be invoked. Seems a bit arbitrary and not something I am likely to remember past my current need. But I think someone working with shells is used to the idea that different functions or commands return numbers indicate certain things. > >> A couple other approaches are setting a variable or calling a routine. >> For example "trap_return --skip" or TRAP_RETURN="skip" > > On the other hand, I can't make this compatible with existing versions > (the standard namespace pollution problem). > > I don't like adding a new builtin just for this. > > The variable version is doable, we've done similar things before. You'd > have to note that it didn't force return from the current environment, > either the inline trap or TRAPDEBUG. You'd also have to be prepared for > the shell to manipulate the variable behind your back, else you'd run > into problems with having it set on future traps. It's not disastrous, > but I'm not convinced this is simpler. In fact, at the moment it seems > to me manifestly much more complicated. > > -- > Peter Stephenson Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 >