[Toybox] Confused by bash trap handler return value.

[Chet Ramey]

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    chet at case.edu    http://tiswww.cwru.edu/~chet/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: OpenPGP digital signature
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20250213/06c109d4/attachment-0001.sig>