Re: XCU: 'exit' trap condition [was:Re: XCU: 'return' from subshell]
Date:Mon, 16 Mar 2020 13:45:28 +0100
From:Joerg Schilling
Message-ID: <5e6f74e8.xgypuzg5wdvjbgqk%joerg.schill...@fokus.fraunhofer.de>
| See my remark about the fact that ksh does not use the same definition of
| "return" as POSIX. All shells thatdo not claim ksh compatibilits
| (which is the majority) do not execute the EXIT trap in that case.
pdksh $ f() ( trap "echo FOO" EXIT; return 5; echo BAR ); f
FOO
mksh $ f() ( trap "echo FOO" EXIT; return 5; echo BAR ); f
FOO
ksh93 $ f() ( trap "echo FOO" EXIT; return 5; echo BAR ); f
FOO
bash$ f() ( trap "echo FOO" EXIT; return 5; echo BAR ); f
FOO
zsh $ f() ( trap "echo FOO" EXIT; return 5; echo BAR ); f
FOO
Now what was it that you were saying ??
The ash derived shells all do the same. I don't have ksh88 to test.
The same result is achieved if the function is
f() { ( ... ) }
Now, there is no doubt that POSIX does not specify what the "return"
there does. That was the original issue. But since all shells we
can find treat that "return" the same as "exit" (however they implement
that) it seems reasonable to specify that.
That an exit trap is not run (eg:
bosh $ f() ( trap "echo FOO" EXIT; return 5; echo BAR ); f
bosh $
) when a shell exits, regardless of the cause of the exit,
seems simply to be a bug to me.
kre
Re: XCU: 'exit' trap condition [was:Re: XCU: 'return' from subshell]
Date:Sun, 15 Mar 2020 14:44:51 +
From:Dirk Fieldhouse
Message-ID: <55e0c45a-f13c-fa1d-db22-4c0a1b02d...@gmx.net>
| > Not that I am aware of. exit is kind of blunt, it is quite hard to
| > be subtly different - I suppose the one difference might be whether the
| > EXIT trap (if there is one) is run, ...
| >...>
|
| Unfortunately this brings a differently flavoured can of worms.
It might, but the following is not it.
| The standard's wording on 'exit' appears to require that the EXIT trap
| is run when exiting a top level shell ("before the shell terminates,"),
Not just a top level shell, any shell.
| and not when execution "continue[s] in the environment from which that
| subshell environment was invoked"
that is beyond doubt, the relevant trap action does not exist in that
environment, it could not possibly be executed there.
You need to read the whole standard to understand it, you cannot simply
read one section here and there and expect that to make sense. It is
not a tutorial, not even an advanced user manual.
| -- which the standard contrasts with
| "otherwise, the shell utility shall terminate...".
I have no idea what the "contrasts" is there.
The first paragraph of the description of exit says what exit does
to the shell (a subshell ends, and the parent continues, the top level
shell simply exits) - it has nothing to do with traps.
The second para says that an exit trap is run just before the shell
exits.
| Should the standard say instead that the trap is executed "before the
| shell exits from the current execution environment,"
It could say that, rather than "terminates", but the effect is the
same - the execution environment terminates (or exits, they mean the
same), or the shell utility terminates (or exits) if the execution
environment is the top level shell. Either way, if that environment has
set an exit trap, the trap commands are run as the final action before
the shell terminates (or exits).
If anything were to change, it would be better to say "before the
current execution environment terminates" - the reason for "terminate"
rather than "exit" is that this is the description of the exit command.
If we just say (in more words) "exit causes the shell to exit" it looks
kind of like a circular definition "x does x" - which is not very
illuminating.Hence "terminate" as the action for the exit command.
But this is just the exit command, none of this has ever been in
doubt, and ...
| so as to avoid misinterpretation?
it is really difficult to believe that any of this part can possibly
be misinterpreted. And no, I don't believe that the wording that
you quoted in your reply to Harald is in any real way confusing.
The issues that arose (the can of worms) are what is to happen when
a subshell execution environment (in a function) ends because of a
return command - all shells have the execution environment end
when that happens, but a couple don't run the exit trap. Since currently
that return gives unspecified results, it would be plausible (if
a little bizarre) for those shells to claim that their unspecified
result is to exit without running an exit trap.
If we were to update the standard to specify that a return command
in a subshell in a function causes the subshell to exit, then we need
to be clear what happens with exit traps.
kre
Re: XCU: 'exit' trap condition [was:Re: XCU: 'return' from subshell]
Dirk Fieldhouse wrote:
> On 15/03/20 07:26, Robert Elz wrote:
> >...>
> >[I wrote:]>| Is there any suggestion that the 'exit'-like
> behaviour of any shell that
> >| implements it for 'return' in such contexts is subtly different from
> > 'exit'?
> >
> > Not that I am aware of. exit is kind of blunt, it is quite hard to
> > be subtly different - I suppose the one difference might be whether the
> > EXIT trap (if there is one) is run, ...
> >...>
>
> Unfortunately this brings a differently flavoured can of worms.
>
> The standard's wording on 'exit' appears to require that the EXIT trap
> is run when exiting a top level shell ("before the shell terminates,"),
> and not when execution "continue[s] in the environment from which that
> subshell environment was invoked" -- which the standard contrasts with
> "otherwise, the shell utility shall terminate...".
See my remark about the fact that ksh does not use the same definition of
"return" as POSIX. All shells thatdo not claim ksh compatibilits (which is the
majority) do not execute the EXIT trap in that case.
Jörg
--
EMail:jo...@schily.net(home) Jörg Schilling D-13353 Berlin
joerg.schill...@fokus.fraunhofer.de (work) Blog: http://schily.blogspot.com/
URL: http://cdrecord.org/private/ http://sf.net/projects/schilytools/files/'
Re: XCU: 'exit' trap condition [was:Re: XCU: 'return' from subshell]
On 15/03/2020 14:44, Dirk Fieldhouse wrote:
On 15/03/20 07:26, Robert Elz wrote:
>...>
>[I wrote:]> | Is there any suggestion that the 'exit'-like
behaviour of any shell that
| implements it for 'return' in such contexts is subtly different
from 'exit'?
Not that I am aware of. exit is kind of blunt, it is quite hard to
be subtly different - I suppose the one difference might be whether the
EXIT trap (if there is one) is run, ...
>...>
Unfortunately this brings a differently flavoured can of worms.
The standard's wording on 'exit' appears to require that the EXIT trap
is run when exiting a top level shell ("before the shell terminates,"),
and not when execution "continue[s] in the environment from which that
subshell environment was invoked" -- which the standard contrasts with
"otherwise, the shell utility shall terminate...".
"Before the shell terminates" is not limited to "before the top level
shell terminates". If a shell terminates, even if it is a subshell that
terminates, any EXIT trap action should be run.
Cheers,
Harald van Dijk
