Date:        Sun, 15 Mar 2020 14:44:51 +0000
    From:        Dirk Fieldhouse <fieldho...@gmx.net>
    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


Reply via email to