Re: PATCH: `try' syntax

[Peter Stephenson <pws@xxxxxxx>]

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 <pws@xxxxxxx>                  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
**********************************************************************