On 2/12/25 5:37 PM, Rob Landley wrote:
It will be 0, unless this script was invoked with SIGWINCH ignored, in which case all bets are off because the trap action never gets run.All bets aren't off, kill is a command, commands exit with a return code, kill is exiting with zero. If the trap handler doesn't run the return code is zero.
The whole test is moot if the script is invoked with SIGWINCH blocked. It's deterministic but useless. The result is misleading.
That's what the comment means. Comment the subshell command out. Seriously, trap handlers never set $? that survives beyond their execution. You should be able to verify that with static code analysis.I know what it _should_ do, the question is how do I confirm that a given implementation _did_ do it and didn't have a regression?
Add static analysis to your testing regime?
How is the testing what it says it's testing? If the behavior changed so the handler DID set the return code, the test's output wouldn't change.Probably (exit $?) would be better.That's a NOP? Ok, to force the handler to run, sure...
Yes.
I just don't think you need it, and you don't need the subshell command.I don't think you need it either.The trap won't get run until after the kill returns; trap actions are not run asynchronously.But the kill returns before the (exit 42) runs.And as long as the signal is delivered by then, it should be fine.So... a kernel other than Linux might delay signal delivery arbitrarily long?
Bash runs on some weird non-Unix systems. Your shell probably won't.
But... ew?
Probably unnecessary. The simple test will work on the systems you're concerned about.
(It's not the SAME handler running again, so the potential starvation issue is the same as a recursive function call. Pilot error.)
I have a compile-time optional configuration setting that limits the number of recursive calls to `eval', and this falls under that.
I plead the 5th on moving targets.We've talked about this before.I didn't say it. I complained about _not_ saying it, but I didn't actually say it.
Not this time. But you know what I've said about chasing moving targets.
(Doesn't help me here, I'd have to do a bash version check before adding -p.To what?I meant that having my test do "$SH -p" on the trap test that calls a potentially builtin kill still gives me the return 0 behavior from kill on the bash currently installed in devuan detinue.
I don't think the -p option does what you think it does. Maybe you mean
`-o posix'.
Chet
--
``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/
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
