Re: return exit code in EXIT trap
On 8/5/22 21:49, Koichi Murase wrote: 2022年8月3日(水) 21:19 Robert E. Griffith : That was an interesting read. The illuminating point for me was the statement to the effect of "the POSIX specification is not meant to describe what it correct or rational, but what historically has been implemented so that existing scripts will remain unbroken". This makes me appreciate Chet's position more. Could you explain your thinking in a little more detail? All that I was saying is what I appreciate more now is that in something as widely used and in various ways as bash is, correctness is not the final determination. There is some 'law' I heard quoted saying something like -- any API that is widely used will have every aspect, both intention and unintentional, exploited and relied upon. A good example is the 'using history to parse strings' solution that you provided to my question in the other thread yesterday. Because of the stability of bash we can use that without a lot of risk that the next version is going to break it. We all have benefited from the stability of bash but sometimes that stability comes with a cost. kre makes a good argument for the correctness of A in his response last night, but I dont hear anyone arguing against the correctness of A -- I dont think that is the point. The POSIX language is broken and before its fixed, it might be more prudent to wait to make yet another change concerning this feature to bash. Personally, I would change it to A now but I am glad that there is inertial that has to be overcome before a change to existing behavior is made. --BobG
Re: return exit code in EXIT trap
Hmmm.. I just got confused when I went to do a test...
$ trap 'echo hi; return' SIGUSR2
$ kill -SIGUSR2 $$
hi
bash: return: can only `return' from a function or sourced script
$ $ echo $BASH_VERSION
5.0.17(1)-release
I also confirmed the same error in the DEBUG trap where you specifically
do need to set the exit code.
I realize now that in my scripts I use a function 'setExitCode() {
return $?; }' function in traps as a stand in for 'return'.
Where can we use 'return' directly in a trap script? What am I not getting?
--BobG
On 8/6/22 00:05, Robert Elz wrote:
I am actually astounded by all of this - both by what is in the
standard, and the way Chet interpreted it.
The language in the standard for return was clearly based upon the
idea that it should act just the same as exit, which is not really
appropriate.
Even at first glance, an "exit" executed anywhere (not really, but I'll
get to that below) in the trap handler causes the shell to exit - and it
is reasonable, when no specific exit code is given, for exit to default
to the status just before the trap fired (though even that isn't as well
defined as it should be).Return is nothing like that - it isn't even
clear that it is specified (not even when the trap fires when a function is
running) that a return in the trap handler can do any more then cause the
function it is lexically defined within to return (which does not mean the
function that happened to be running at the time). That to me looks
unspecified (in at least the latest wording).
Even exit should not arbitrarily default to the exit code before the trap
started - that should only apply to instances of exit which cause the shell
invoking the trap to actually exit, not ones in some sub-shell which only
cause that sub-shell to exit, or even worse, an entirely different shell,
like
trap "$OTHERSHELL -c 'grep pattern /some/file >/dev/null ; exit'" SIG
where OTHERSHELL is not necessarily even the same command as the one
running the trap command (consider one is bash, the other is dash) - but
from the language, as it is, in the standard, that exit is in a trap handler,
so should exit with the status the other shell had before the trap was
invoked.
That's patently absurd, and not only does no shell implement that, there is
no mechanism by which it could (no way to invoke OTHERSHELL and tell it what
the exit status was in the invoking shell).
The language in POSIX is clearly broken, and needs fixing. What's kind of
amazing is that none of the "primary" austin group people made any responses
at all to the mailing list discussion.
Clearly this needs a posix defect report filed, if no-one else does that
today, I probably will.
kre
Re: return exit code in EXIT trap
2022年8月7日(日) 1:02 Robert E. Griffith : > Where can we use 'return' directly in a trap script? What am I not getting? It is described in the very original thread: https://lists.gnu.org/archive/html/bug-bash/2014-03/msg00053.html -- Koichi
Re: return exit code in EXIT trap
Date:Sat, 6 Aug 2022 12:02:07 -0400 From:"Robert E. Griffith" Message-ID: <5a091673-5e70-baee-0874-1c8c5ec88...@junga.com> | Where can we use 'return' directly in a trap script? What am I not getting? I suspect that if you want specified behaviour, the answer is nowhere. However, almost all shells extend (one way or another) the places where return/break/continue can be used beyond what is specified in the standard. It just is done differently. It is possible (and seems so, from messages in this thread) that bash allows a return in the trap string (not in a function called in that string) if the trap occurs while executing a function (then the return applies to that function). kre
Re: return exit code in EXIT trap
On 8/6/22 14:44, Robert Elz wrote:
... bash allows a return in the trap string (not in a function called in that
string) if the
trap occurs while executing a function (then the return applies to that
function). ...
Yes! that is what I was missing. Years ago when I wrote my debugger, I
must have come across this and through trail and error I settled on
ending the DEBUG trap with 'setExitCode $action' (where .. setExitCode()
{ return $?; })
Even though I knew that bash did not push anything on the stack when it
called a trap script I always thought there must be some notion of
entering into and returning from a trap script but no, return in a trap
function is just like inserting a return in the interrupted script,
where ever its at!
Here is a test script that I just used to understand and confirm for
myself whats going on and that also illustrates the B behavior
bash5.0.16$ cat bin/test.sh
#!/usr/bin/env bash
function setExitCode() { return $1; }
function f1() {
sleep 2
echo "f1 -- woke, no signal -- ending normally"
return 101
}
function childFn() {
trap 'echo "SIG: signal received -- ending f1 with last code 202 -> return
"; setExitCode 202; return 'SIGUSR1
trap 'echo "SIG: signal received -- ending f1 with last code 202 -> return
\$?"; setExitCode 202; return $?' SIGUSR2
f1
echo "f1 returned $?"
}
childFn &
child="$!"
sleep 1
case $1 in
1) echo "main: sending USR1"; kill -SIGUSR1 $child ;;
2) echo "main: sending USR2"; kill -SIGUSR2 $child ;;
*) echo "main: twiddling thumbs" ;;
esac
wait
echo
bash5.0.16$ bin/test.sh
main: twiddling thumbs
f1 -- woke, no signal -- ending normally
f1 returned 101
bash5.0.16$ bin/test.sh 1
main: sending USR1
SIG: signal received -- ending f1 with last code 202 -> return
f1 returned 0
bash5.0.16$ bin/test.sh 2
main: sending USR2
SIG: signal received -- ending f1 with last code 202 -> return $?
f1 returned 202
bash5.0.16$
The second run (that causes USR1 to interrupt f1) shows the B behavior
compared to the third (USR2) that shows the more correct A behavior by
explicitly using 'return $?'
--BobG
