[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Exit status by no-argument `return' for function calls in tr

From: Chet Ramey
Subject: Re: [PATCH] Exit status by no-argument `return' for function calls in trap handlers
Date: Sat, 18 Apr 2020 16:12:01 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.7.0

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    address@hidden    http://tiswww.cwru.edu/~chet/

reply via email to

[Prev in Thread] Current Thread [Next in Thread]