From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6679 invoked from network); 14 Jun 2004 13:57:12 -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:57:12 -0000 Received: (qmail 16149 invoked from network); 14 Jun 2004 13:54:09 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 14 Jun 2004 13:54:09 -0000 Received: (qmail 5925 invoked by alias); 14 Jun 2004 13:53:45 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 20040 Received: (qmail 5916 invoked from network); 14 Jun 2004 13:53:45 -0000 Received: from thor.dotsrc.org (HELO a.mx.sunsite.dk) (qmailr@130.225.247.86) by sunsite.dk with SMTP; 14 Jun 2004 13:53:42 -0000 Received: (qmail 13424 invoked from network); 14 Jun 2004 13:52:48 -0000 Received: from lhuumrelay3.lnd.ops.eu.uu.net (62.189.58.19) by a.mx.sunsite.dk with SMTP; 14 Jun 2004 13:52:46 -0000 Received: from MAILSWEEPER01.csr.com (mailhost1.csr.com [62.189.183.235]) by lhuumrelay3.lnd.ops.eu.uu.net (8.11.0/8.11.0) with ESMTP id i5EDqJv15753 for ; Mon, 14 Jun 2004 13:52:20 GMT Received: from EXCHANGE02.csr.com (unverified [192.168.137.45]) by MAILSWEEPER01.csr.com (Content Technologies SMTPRS 4.3.12) with ESMTP id for ; Mon, 14 Jun 2004 14:51:42 +0100 Received: from news01.csr.com ([192.168.143.38]) by EXCHANGE02.csr.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 14 Jun 2004 14:55:25 +0100 Received: from news01.csr.com (localhost.localdomain [127.0.0.1]) by news01.csr.com (8.12.11/8.12.11) with ESMTP id i5EDqIx8015452 for ; Mon, 14 Jun 2004 14:52:18 +0100 Received: from csr.com (pws@localhost) by news01.csr.com (8.12.11/8.12.11/Submit) with ESMTP id i5EDqIW2015449 for ; Mon, 14 Jun 2004 14:52:18 +0100 Message-Id: <200406141352.i5EDqIW2015449@news01.csr.com> X-Authentication-Warning: news01.csr.com: pws owned process doing -bs To: zsh-workers@sunsite.dk (Zsh hackers list) Subject: Re: PATCH: `try' syntax In-reply-to: "Oliver Kiddle"'s message of "Mon, 14 Jun 2004 14:58:17 +0200." <5284.1087217897@trentino.logica.co.uk> Date: Mon, 14 Jun 2004 14:52:18 +0100 From: Peter Stephenson X-OriginalArrivalTime: 14 Jun 2004 13:55:25.0132 (UTC) FILETIME=[3E02E8C0:01C45217] 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=BAYES_50 autolearn=no version=2.63 X-Spam-Hits: 0.0 Oliver Kiddle wrote: > What exactly do break, continue and return do here? Are they unchanged, > expecting an enclosing loop or function. Yes. The description in the manual is supposed to say that. > 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. I thought about that, but it thoroughly obscures the effect of breaks and continues. > Is it possible to put the command after try and always. e.g: > :try do-stuff; :always rm $tempfile; :tried Yes, as it says in the manual entry the breaks afterward are optional. > What sort of things does an "error condition" encompass? Is it just > exit signals? It isn't clear without an example. Whenever errflag is 1 internally: a brief summary is it is set for syntax errors and gross failures to carry out user requests. In other words, anything which would case the rest of the code to be skipped without a user command (return etc.). One example couldn't make that clear, but would probably be useful anyway. > It could be useful to > have something like the errexit and errreturn options apply within the > try block. They do, but to the enclosing function (the always block would be executed). Again, trying to make the try block do something more than its basic purpose seemed to me a bad idea. I specifically designed it *not* to change the basic flow. > `unset -e' seems a bit obscure. Would an option to exit or return make > it clearer what is happening. No, for the same reason. It's not an exit or a return. > Or how about using special variable which > indicates what the "error condition" is and have that be unset. Yes, that's possible, and it allows you to test for an error, too, which the current syntax doesn't. Again, I couldn't think of a good name which didn't potentially clash with a user variable. Perhaps TRY_ERROR or even TRY_BLOCK_ERROR would be good enough. (It's not a status; $? correctly indicates the status after the try block, but not whether an error occurred.) (I wonder if it could be setable inside the try block to force errflag to 1, forcing the rest of the block to be skipped? That would give a nice interaction with traps. This is getting dangerously close to `throw'.) > The colons make them look like labels. Not in any UNIX shell I've ever seen. > You could avoid `tried' by using > `done' or, being consistent with esac and fi, use `yrt'. Another option > could be to use uppercase. That doesn't remove the basic problem, although upper case is a good idea. > Or could it go in a module? Not without a lot of nasty rewriting and potential inconsistency. It *could* be done, though. > Does this actually do anything which traps can't do? Can we perhaps > change something about traps to make them simpler to use. Traps aren't actually designed for this purpose at all. There's no way of making sure a trap gets executed, because there wasn't supposed to be --- they give code to run under particular circumstances, not a catch-all which does nothing but ensure a chunk of code is always executed. There's no easy way of restricting a trap to a block scope, either, so even a new trap set at a similar point wouldn't really do the job. The point about the new syntax is it's structural, not event-driven. This is a key difference for the type of use I envisage (and indeed have wanted in the past). You *could* probably add a special unconditional exit trap and require people to embed stuff in functions if they want to use it. It's certainly not simpler, though, and it won't have the effect of allowing breaks and continues to apply to surrounding loops. > It doesn't > look quite as versatile, for example you can't setup timeout delays. It's not supposed to be, it's for a quite different purpose. However, you could probably mix a timeout with the use of an always block. That's part of the reason for wondering whether the error flag should be settable. -- Peter Stephenson Software Engineer CSR Ltd., Science Park, Milton Road, Cambridge, CB4 0WH, UK Tel: +44 (0)1223 692070 ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This footnote also confirms that this email message has been swept by MIMEsweeper for the presence of computer viruses. www.mimesweeper.com **********************************************************************