On 4/16/20 1:21 PM, Koichi Murase wrote:
> Bash Version: 5.0
> Patch Level: 11
> Release Status: release
>
> Summary:
>
> The behavior of no-argument `return' in trap handlers has been
> changed from Bash 4.4 to follow the description of POSIX. Recently
> this behavior caused problems in my Bash script. I am wondering
> whether this change actually matches with the behavior meant by
> POSIX because the change introduces unreasonable constraints in
> writing shell functions.
>
> For the condition of this special treatment of `return', POSIX says
> ``When return is executed in a trap action''. Here are two possible
> interpretation: (A) `return's specified in the argument string of
> `trap' builtin are affected, or (B) all the `return's in entire
> runtime function-call tree in trap processing are affected. I guess
> that POSIX wanted to provide a way to exit functions that received
> signals without changing the value of `$?'. If that is the case,
> the POSIX should have meant (A). However, the current Bash
> implementation behaves as if it follows the interpretation (B).
The POSIX wording seems straightforward and implies (B). The `action'
is a string that is defined to behave as if it were the argument to
`eval', so it can be an arbitrary command, which makes (A) unlikely.
You could always ask the austin-group list for an interpretation, or
send me something that I could forward to the list for you.
> If all the `return's in the entire function-call tree are affected
> in trap processing as in the interpretation (B), one cannot reliably
> use no-argument `return' to return the last-command exit status. To
> avoid the problem, one has to always write the exit status
> explicitly as `return $?', and there is no use case for no-argument
> `return' at all.
That's an unreasonable statement, throwing out all uses of return without
an argument because of how it behaves while running a trap.
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU c...@case.edu http://tiswww.cwru.edu/~chet/
