From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6962 invoked from network); 14 Jun 2004 13:00:09 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.86) by ns1.primenet.com.au with SMTP; 14 Jun 2004 13:00:09 -0000 Received: (qmail 550 invoked from network); 14 Jun 2004 12:59:46 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Jun 2004 12:59:46 -0000 Received: (qmail 16329 invoked by alias); 14 Jun 2004 12:59:41 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20038 Received: (qmail 16319 invoked from network); 14 Jun 2004 12:59:41 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 14 Jun 2004 12:59:38 -0000 Received: (qmail 32597 invoked from network); 14 Jun 2004 12:59:33 -0000 Received: from mail36.messagelabs.com (193.109.254.211) by a.mx.sunsite.dk with SMTP; 14 Jun 2004 12:59:29 -0000 X-VirusChecked: Checked X-Env-Sender: okiddle@yahoo.co.uk X-Msg-Ref: server-10.tower-36.messagelabs.com!1087217942!6956322 X-StarScan-Version: 5.2.10; banners=-,-,- X-Originating-IP: [158.234.9.163] Received: (qmail 13206 invoked from network); 14 Jun 2004 12:59:02 -0000 Received: from iris.logica.co.uk (158.234.9.163) by server-10.tower-36.messagelabs.com with SMTP; 14 Jun 2004 12:59:02 -0000 Received: from trentino.logica.co.uk ([158.234.142.61]) by iris.logica.co.uk (8.12.3/8.12.3/Debian -4) with ESMTP id i5ECx1UI020765 for ; Mon, 14 Jun 2004 13:59:01 +0100 Received: from trentino.logica.co.uk (localhost [127.0.0.1]) by trentino.logica.co.uk (Postfix) with ESMTP id 3EE5B7A7B695 for ; Mon, 14 Jun 2004 14:58:17 +0200 (CEST) X-VirusChecked: Checked X-StarScan-Version: 5.0.7; banners=.,-,- In-reply-to: <200406141123.i5EBNdoM012078@news01.csr.com> From: Oliver Kiddle References: <200406141123.i5EBNdoM012078@news01.csr.com> To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: PATCH: `try' syntax Date: Mon, 14 Jun 2004 14:58:17 +0200 Message-ID: <5284.1087217897@trentino.logica.co.uk> X-Spam-Checker-Version: SpamAssassin 2.63 on a.mx.sunsite.dk X-Spam-Level: X-Spam-Status: No, hits=0.0 required=6.0 tests=none autolearn=no version=2.63 X-Spam-Hits: 0.0 Peter wrote: > The basic idea is: > > :try > # Code here runs normally > :always > # Code here always gets run, even if there is a fatal > # error (unless it crashes the shell), or a return, break, > # or continue in the :try block. What exactly do break, continue and return do here? Are they unchanged, expecting an enclosing loop or function. It'd be really useful to have a way to skip over the rest of the try block, going straight to the always code. The best way to handle that would be to use break with the try block appearing to be a loop. But we probably don't want break and continue numbers to be out of sync so perhaps both should have that effect. Is it possible to put the command after try and always. e.g: :try do-stuff; :always rm $tempfile; :tried > # > # Optionally: > unset -e > # removes any error condition. Apart from that, after exiting > # the always block, the logic is as if it hadn't been present. What sort of things does an "error condition" encompass? Is it just exit signals? It isn't clear without an example. It could be useful to have something like the errexit and errreturn options apply within the try block. `unset -e' seems a bit obscure. Would an option to exit or return make it clearer what is happening. Or how about using special variable which indicates what the "error condition" is and have that be unset. > The trickiest bit is the naming. I wanted something reasonably > memorable, but without polluting the name space, hence the names > with the colons in front. Note that `disable -r :try :always :tried' > works. The colons make them look like labels. You could avoid `tried' by using `done' or, being consistent with esac and fi, use `yrt'. Another option could be to use uppercase. Or could it go in a module? We ought to fix completion to do something about colons in command-names in the current context. What you see with: : is not ideal. Does this actually do anything which traps can't do? Can we perhaps change something about traps to make them simpler to use. It doesn't look quite as versatile, for example you can't setup timeout delays. Oliver