On 19/04/2020 14:32, Koichi Murase wrote:
2020-04-19 21:55 Harald van Dijk <[email protected]>:
My reading was that interpretation B must be what is intended, which
is why I had modified my shell, a fork of dash, to change dash's A
behaviour to B in late 2018.
Thank you. Is your shell this https://github.com/hvdijk/gwsh ? I
tried gwsh-0.5.9.1. Here is the updated list:
Yes, that is my shell. Pay no attention to that version number, that is
dash's version number that I have not updated because I never did a
proper release yet. :)
(A) `zsh', `dash', `busybox', `heirloom-sh'
(B) `bash-4.4', `mksh', `ksh', `gwsh'
(C) `yash'
(D) none
Not Implemented: `bash-4.3', `posh'
My reasoning for that is that the description of the return
commanhd ("When return is executed in a trap action, the last
command is considered to be the command that executed immediately
preceding the trap action.") is identical to that of the exit
command ("When exit is executed in a trap action, the last command
is considered to be the command that executed immediately preceding
the trap action.")
Thank you. This is a good point. Maybe this is the origin of the
current wording.
and for the exit command, almost all shells, including dash, are in
agreement that it applies even when the exit command is invoked
indirectly. [...]
It is reasonable that indirect `exit' in function calls in trap
handlers are affected because it actually brings the completion of
trap action which is more consistent with the following description of
`trap'. While, the trap action will not be completed by indirect
`return', so it is not surprising that the behavior can be different
between `exit' and `return'.
True, and if the intent is that exit and return behave differently and
the standard is updated to clearly require that, I have no problem
changing the shell back to the prior behaviour.
It does still mean that anyone writing a function needs to beware that
exit and exit $? do not have the same effect, if there is any
possibility that the function will be invoked from a trap action. I
suspect most people writing functions will not be aware of that.
Another question is what the behaviour should be in a subshell. That is:
f() { false; return; } # or exit
trap '(f; echo $?)' EXIT
Is the return or exit here still considered to execute within a trap
action, or does the fact that subshells reset traps mean that whatever
was executing in the parent shell can no longer be considered a trap
action within the subshell?
Cheers,
Harald van Dijk
