Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > gnu.bash.bug > #16167
| From | Chet Ramey <chet.ramey@case.edu> |
|---|---|
| Newsgroups | gnu.bash.bug |
| Subject | Re: [PATCH] Exit status by no-argument `return' for function calls in trap handlers |
| Date | 2020-04-18 16:12 -0400 |
| Organization | ITS, Case Western Reserve University |
| Message-ID | <mailman.623.1587240727.3066.bug-bash@gnu.org> (permalink) |
| References | <CAFLRLk_+Je7ZHEYp_a4PLBwYFZffqfsYgp5jtPCnAH=apmHatQ@mail.gmail.com> <7f1850ca-fb02-35db-e1f6-80d7ae937ff8@case.edu> |
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 chet@case.edu http://tiswww.cwru.edu/~chet/
Back to gnu.bash.bug | Previous | Next | Find similar
Re: [PATCH] Exit status by no-argument `return' for function calls in trap handlers Chet Ramey <chet.ramey@case.edu> - 2020-04-18 16:12 -0400
csiph-web