{ exit } always { foo }

{ exit } always { foo }

[Daniel Shahaf]

The documentation of the try-always construct says:

    An tt(exit) command (or a tt(return) command executed at the outermost
    function level of a script) encountered in tt(try-list) does em(not) cause
    the execution of var(always-list).  Instead, the shell exits immediately
    after any tt(EXIT) trap has been executed.

However, A01grammar.ztst expects the always-list to be run:

  723	  (
  724	  mywrap() { echo BEGIN; true; echo END }
  725	  mytest() { { exit 3 } always { mywrap }; print Exited before this }
  726	  mytest
  727	  print Exited before this, too
  728	  )
  729	3:Exit and always block with functions: simple
  730	>BEGIN
  731	>END

Which is correct, the manual or the test?

Re: { exit } always { foo }

[Bart Schaefer]

On Tue, Dec 17, 2019 at 7:57 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Which is correct, the manual or the test?

I think both are, although the wording in the doc might be clearer.
This is the important bit (my capitals):

>     An tt(exit) command (or a tt(return) command executed AT THE OUTERMOST
>     function LEVEL of a script) encountered in tt(try-list) does em(not) cause
>     the execution of var(always-list).  Instead, the shell exits immediately
>     after any tt(EXIT) trap has been executed.

The word "function" there is unfortunate because it doesn't mean a
shell function.

In this line:
>   725     mytest() { { exit 3 } always { mywrap }; print Exited before this }

The always block is NOT at the outermost level, so the shell does not
exit immediately.  "Outermost" means that there IS NO surrounding
function scope.  Thus in the following case:

 (
  mywrap() { echo BEGIN; true; echo END }
  { exit 3 } always { mywrap }; print Exited before this
 )

The always block is not executed and mywrap isn't called.  As soon as
you put the "always" inside the "mytest" scope, that rule no longer
applies.

Re: { exit } always { foo }

[Bart Schaefer]

On Tue, Dec 17, 2019 at 8:54 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> The word "function" there is unfortunate because it doesn't mean a
> shell function.

Well, strictly I guess it does mean a shell function because that's
the only way to introduce another scope, but it's confusing to think
of "the level where no shell function has been introduced yet" as a
"function level".  It's sort of like calling the sidewalk in front of
a building the "outermost floor".

Re: { exit } always { foo }

[Daniel Shahaf]

Bart Schaefer wrote on Tue, Dec 17, 2019 at 20:54:44 -0800:
> On Tue, Dec 17, 2019 at 7:57 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > Which is correct, the manual or the test?
> 
> I think both are, although the wording in the doc might be clearer.
> This is the important bit (my capitals):
> 
> >     An tt(exit) command (or a tt(return) command executed AT THE OUTERMOST
> >     function LEVEL of a script) encountered in tt(try-list) does em(not) cause
> >     the execution of var(always-list).  Instead, the shell exits immediately
> >     after any tt(EXIT) trap has been executed.

The way I read this is, it says that such-and-such will happen whenever
_either_ of the following two constructs is seen:

- 'exit' is invoked by try-list (possibly in a deep callee)

- 'return' is invoked, outside of any function, in a try-list

That is, the "at the outermost level" qualifier applies only to 'return', not
to 'exit'.  This interpretation is supported by the parentheses.  (This is one
of the rare cases in which English is explicit about its syntactic precedece rules.)

Under this reading, the docs promise that the test's behaviour will be the same regardless
of whether or not the 'exit' happens to be in a function.

> In this line:
> >   725     mytest() { { exit 3 } always { mywrap }; print Exited before this }
> 
> The always block is NOT at the outermost level, so the shell does not
> exit immediately.  "Outermost" means that there IS NO surrounding
> function scope.  Thus in the following case:
> 
>  (
>   mywrap() { echo BEGIN; true; echo END }
>   { exit 3 } always { mywrap }; print Exited before this
>  )
> 
> The always block is not executed and mywrap isn't called.  As soon as
> you put the "always" inside the "mytest" scope, that rule no longer
> applies.

Good catch.  Based on the manual, I would have expected such a difference to
manifest if the two cases had used 'return 3', but not if they used 'exit 3'.

Furthermore, it makes intuitive sense for 'return' to behave in one way inside
a function, and in another way — like 'exit' — when not inside a function; but
I don't immediately see why it makes sense for 'exit' to change behaviour
depending on when it's inside a function or not.  Compare:

1.
    mywrap() { echo BEGIN; true; echo END }
        { exit 3 } always { mywrap }; print Exited before this

2.
    mywrap() { echo BEGIN; true; echo END }
    (){ { exit 3 } always { mywrap }; print Exited before this }

So, personally, I would find it more intuitive to change the implementation to
match the documentation, than the other way around.

Bart Schaefer wrote on Tue, Dec 17, 2019 at 20:59:01 -0800:
> On Tue, Dec 17, 2019 at 8:54 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > The word "function" there is unfortunate because it doesn't mean a
> > shell function.
> 
> Well, strictly I guess it does mean a shell function because that's
> the only way to introduce another scope, but it's confusing to think
> of "the level where no shell function has been introduced yet" as a
> "function level".  It's sort of like calling the sidewalk in front of
> a building the "outermost floor".

It's intuitive enough to me.  It's pretty common in math contexts, too: for
example, one can scale down quadratic equations and linear equations to
zeroth-degree equations (a₀⋅x⁰ = 0, solve for $x$).  Makes perfect sense.
(No promises about usefulness, though.)

Cheers,

Daniel

Re: { exit } always { foo }

[Daniel Shahaf]

Daniel Shahaf wrote on Wed, 18 Dec 2019 05:23 +00:00:
> So, personally, I would find it more intuitive to change the implementation to
> match the documentation, than the other way around.

I'll wait a bit more for feedback.  If the decision ends up being to change the
implementation to match the documentation, I'll at least document it as
a bug/incompatibility, or maybe fix it if I manage that.

I found this while testing patches related to Martijn's bug (44007).  Once
this bug is resolved I'll get back to 44007.

Re: { exit } always { foo }

[Peter Stephenson]

On Thu, 2019-12-19 at 15:28 +0000, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Wed, 18 Dec 2019 05:23 +00:00:
> > 
> > So, personally, I would find it more intuitive to change the implementation to
> > match the documentation, than the other way around.
> I'll wait a bit more for feedback.  If the decision ends up being to change the
> implementation to match the documentation, I'll at least document it as
> a bug/incompatibility, or maybe fix it if I manage that.

I don't think it's that big a deal either way as long as the inconsistency
gets fixed; I'd be happy to leave it to what ever feels most natural if you're
using the feature in question.

cheers
pws

Re: { exit } always { foo }

[Daniel Shahaf]

Peter Stephenson wrote on Thu, 19 Dec 2019 15:37 +00:00:
> On Thu, 2019-12-19 at 15:28 +0000, Daniel Shahaf wrote:
> > Daniel Shahaf wrote on Wed, 18 Dec 2019 05:23 +00:00:
> > > 
> > > So, personally, I would find it more intuitive to change the implementation to
> > > match the documentation, than the other way around.
> > I'll wait a bit more for feedback.  If the decision ends up being to change the
> > implementation to match the documentation, I'll at least document it as
> > a bug/incompatibility, or maybe fix it if I manage that.
> 
> I don't think it's that big a deal either way as long as the inconsistency
> gets fixed; I'd be happy to leave it to what ever feels most natural if you're
> using the feature in question.

I think there are actually two separate questions here:

- Whether 'return outside of any function' should be equivalent to 'exit'

- Whether the always-list should be run if the try-list does an exit

I'm not sure what my answers to these questions any more.

For that matter, should the always-list run if a SIGINT is received during the
try-list?  What about SIGQUIT?  The documentation only says the always-list
will be executed in case of "a condition such as a syntax error which causes
the shell to abort execution [...]".

Hmm…

Daniel