Re: PATCH: `try' syntax

[Oliver Kiddle <okiddle@yahoo.co.uk>]

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:
: <Ctrl-x><h>
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