<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Mar 15, 2024 at 2:22 PM Rob Landley <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 3/15/24 13:40, enh via Toybox wrote:<br>
> i've never noticed these before:<br>
> <br>
>        --block-signal[=SIG]<br>
>               block delivery of SIG signal(s) to COMMAND<br>
> <br>
>        --default-signal[=SIG]<br>
>               reset handling of SIG signal(s) to the default<br>
> <br>
>        --ignore-signal[=SIG]<br>
>               set handling of SIG signal(s) to do nothing<br>
> <br>
> i've not yet _needed_ them, but fyi in case anyone does. (the motivating example<br>
> in the man page is "making sure SIGPIPE actually works in a child, regardless of<br>
> the caller's signal disposition".)<br>
<br>
In 2011, I had an adventure, the punchline of which is here:<br>
<br>
<a href="https://landley.net/notes-2011.html#05-09-2011" rel="noreferrer" target="_blank">https://landley.net/notes-2011.html#05-09-2011</a><br>
<br>
And the investigation leading up to it was:<br>
<br>
<a href="https://landley.net/notes-2011.html#24-08-2011" rel="noreferrer" target="_blank">https://landley.net/notes-2011.html#24-08-2011</a><br>
<a href="https://landley.net/notes-2011.html#26-08-2011" rel="noreferrer" target="_blank">https://landley.net/notes-2011.html#26-08-2011</a><br>
<a href="https://landley.net/notes-2011.html#28-08-2011" rel="noreferrer" target="_blank">https://landley.net/notes-2011.html#28-08-2011</a><br>
<a href="https://landley.net/notes-2011.html#01-09-2011" rel="noreferrer" target="_blank">https://landley.net/notes-2011.html#01-09-2011</a><br>
<a href="https://landley.net/notes-2011.html#02-09-2011" rel="noreferrer" target="_blank">https://landley.net/notes-2011.html#02-09-2011</a><br>
<a href="https://landley.net/notes-2011.html#03-09-2011" rel="noreferrer" target="_blank">https://landley.net/notes-2011.html#03-09-2011</a><br>
<a href="https://landley.net/notes-2011.html#04-09-2011" rel="noreferrer" target="_blank">https://landley.net/notes-2011.html#04-09-2011</a><br>
<br>
tl;dr: autoconf was hanging in one of its tests, I safari'd through to the<br>
actual failure reproduction sequence then traced it THROUGH the kernel to<br>
eventually find an old bash bug (longjmp instead of siglongjmp) so when bash<br>
took a timeout trap it left SIGALRM blocked, and my PID 1 init script had a<br>
"read -t 3" that was doing that, meaning child processes that script started<br>
inherited the blocked SIGALRM, which didn't cause a problem until halfway<br>
through an autoconf build.<br>
<br>
That said, I'm not implementing --longopts without a short opt until somebody<br>
comes to me with a use case. And then I would come up with short options. Also,<br>
"env" is probably the wrong place to put this unless it's also going to sprout<br>
flags to change niceness level and so on: man 7 signal and man 7 environ are<br>
different pages.<br></blockquote><div><br></div><div>i know what you mean, but at the same time, the fact that this swiss army knife doesn't actually exist is a bug in its own right. i regularly find people who don't realize which of these things there is/isn't a command for. (because not only are they separate commands, even the man pages don't generally refer to one another. because, like you say, in a sense they _don't_ have anything much to do with one another.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Rob<br>
</blockquote></div></div>