[Toybox] interesting new (?) env(1) options

Rob Landley rob at landley.net
Fri Mar 15 14:31:07 PDT 2024


On 3/15/24 13:40, enh via Toybox wrote:
> i've never noticed these before:
> 
>        --block-signal[=SIG]
>               block delivery of SIG signal(s) to COMMAND
> 
>        --default-signal[=SIG]
>               reset handling of SIG signal(s) to the default
> 
>        --ignore-signal[=SIG]
>               set handling of SIG signal(s) to do nothing
> 
> i've not yet _needed_ them, but fyi in case anyone does. (the motivating example
> in the man page is "making sure SIGPIPE actually works in a child, regardless of
> the caller's signal disposition".)

In 2011, I had an adventure, the punchline of which is here:

https://landley.net/notes-2011.html#05-09-2011

And the investigation leading up to it was:

https://landley.net/notes-2011.html#24-08-2011
https://landley.net/notes-2011.html#26-08-2011
https://landley.net/notes-2011.html#28-08-2011
https://landley.net/notes-2011.html#01-09-2011
https://landley.net/notes-2011.html#02-09-2011
https://landley.net/notes-2011.html#03-09-2011
https://landley.net/notes-2011.html#04-09-2011

tl;dr: autoconf was hanging in one of its tests, I safari'd through to the
actual failure reproduction sequence then traced it THROUGH the kernel to
eventually find an old bash bug (longjmp instead of siglongjmp) so when bash
took a timeout trap it left SIGALRM blocked, and my PID 1 init script had a
"read -t 3" that was doing that, meaning child processes that script started
inherited the blocked SIGALRM, which didn't cause a problem until halfway
through an autoconf build.

That said, I'm not implementing --longopts without a short opt until somebody
comes to me with a use case. And then I would come up with short options. Also,
"env" is probably the wrong place to put this unless it's also going to sprout
flags to change niceness level and so on: man 7 signal and man 7 environ are
different pages.

Rob


More information about the Toybox mailing list