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