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 _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
