return exit code in EXIT trap
Is it known behavior that return without a parameter will not set the
exit code from the last command when called from the EXIT trap?
$ cat -n exitReturnBug.sh
1 #!/usr/bin/bash
2 function shouldReturnFalse() {
3 false
4 return
5 }
6 trap 'shouldReturnFalse && echo "woops"' EXIT
$ ./exitReturnBug.sh
woops
If I change line 4 to "return $?" it will not print "woops" which is the
correct behavior.
I tested this in 5.0.17 and 5.1.16.
--BobG
Re: return exit code in EXIT trap
On 8/2/22 3:38 PM, Robert E. Griffith wrote: > Is it known behavior that return without a parameter will not set the exit > code from the last command when called from the EXIT trap? https://getyarn.io/_nuxt/f66cb012eec875e1f9262fd77ecdf31e.svg https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00089.html -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: return exit code in EXIT trap
Oh darn, I have been writing bash scripts for a long time and have never found a novel bug. I was hoping this would be my first:) The first (getyarn...) link renders as a blank page for me. What it is supposed to be? Is there a reason why POSIX would want the return behavior to of function down the stack to behave differently when in a trap? Seems strange to me. It does seem like I have to go through all my library type functions and add a "$?" to every return since I cant guarantee that they wont indirectly be called from a trap. --BobG On 8/2/22 15:55, Chet Ramey wrote: On 8/2/22 3:38 PM, Robert E. Griffith wrote: Is it known behavior that return without a parameter will not set the exit code from the last command when called from the EXIT trap? https://getyarn.io/_nuxt/f66cb012eec875e1f9262fd77ecdf31e.svg https://lists.gnu.org/archive/html/bug-bash/2020-04/msg00089.html
Re: return exit code in EXIT trap
On 8/2/22 4:18 PM, Robert E. Griffith wrote: The first (getyarn...) link renders as a blank page for me. What it is supposed to be? https://getyarn.io/yarn-clip/cea30edb-a7a6-465b-bc51-3d53d9281447 Is there a reason why POSIX would want the return behavior to of function down the stack to behave differently when in a trap? Seems strange to me. I don't remember if Koichi ever opened up a bug with the Austin Group. Until then, I'm going by the plain language of the standard. It seems more strange that POSIX would have intended this to mean only a `return' in the actual action string (A) instead of while the trap action is executing (B). -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: return exit code in EXIT trap
https://getyarn.io/yarn-clip/cea30edb-a7a6-465b-bc51-3d53d9281447 It was worth the wait:) --BobG On 8/2/22 16:57, Chet Ramey wrote: On 8/2/22 4:18 PM, Robert E. Griffith wrote: The first (getyarn...) link renders as a blank page for me. What it is supposed to be? https://getyarn.io/yarn-clip/cea30edb-a7a6-465b-bc51-3d53d9281447 Is there a reason why POSIX would want the return behavior to of function down the stack to behave differently when in a trap? Seems strange to me. I don't remember if Koichi ever opened up a bug with the Austin Group. Until then, I'm going by the plain language of the standard. It seems more strange that POSIX would have intended this to mean only a `return' in the actual action string (A) instead of while the trap action is executing (B).
Re: return exit code in EXIT trap
2022年8月3日(水) 5:57 Chet Ramey : > On 8/2/22 4:18 PM, Robert E. Griffith wrote: > > Is there a reason why POSIX would want the return behavior to of function > > down the stack to behave differently when in a trap? Seems strange to me. > > I don't remember if Koichi ever opened up a bug with the Austin Group. This is the thread in the Austin Group list: https://www.mail-archive.com/austin-group-l@opengroup.org/msg06011.html A summary of the current situation is found in this reply. I haven't received any further replies to this reply. https://www.mail-archive.com/austin-group-l@opengroup.org/msg06030.html The specification of POSIX is clearly ambiguous, and no one seems to know which one is the correct interpretation. The behavior [(A), (B), or whatever] seems to be effectively *unspecified* in POSIX because POSIX seems just to summarize the common feature set of "existing implementations" but there is no convergence among them. > Until then, I'm going by the plain language of the standard. It seems more > strange that POSIX would have intended this to mean only a `return' in the > actual action string (A) instead of while the trap action is executing (B). >From POSIX's perspective, the current behavior of bash-4.4+ [i.e., behavior (B)] is nothing wrong as it is effectively unspecified, but behavior (A) seems still more reasonable to me. Behavior (B) is a source of problems for me because `return' without arguments cannot be used inside functions, or we need to remember which function contains `return' without arguments to write trap strings. Currently, I am avoiding writing `return' but instead always writing `return "$?"' as a workaround, but I don't think every user knows this. Also, I am wondering if there is any actual use case of behavior (B). On the other hand, the top-level `return' in trap strings can be used to change the control path in signaled functions. I think behavior A can be useful in such a case when one wants to exit the function without affecting $?. -- Koichi
