[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