2020-04-19 21:55 Harald van Dijk <a...@gigawatt.nl>: > 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: (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'. >>>> [XCU 2.14 Special Built-In Utilities - trap - DESCRIPTION/paragraph 2] >>>> >>>> [...] The value of "$?" after the trap action completes shall be >>>> the value it had before trap was invoked. -- Koichi
