[Toybox] default SIGPIPE handler that calls _exit(0)?
Rob Landley
rob at landley.net
Fri Feb 10 14:39:53 PST 2017
On 02/09/2017 03:50 PM, enh wrote:
> this just came up again. the (internal) bug report being "`ps -A |
> head -n1` shouldn't die with SIGPIPE".
>
> i think from this thread we agreed that there shouldn't be any
> top-level SIGPIPE handler, with grep being an example where SIGPIPE is
> the least worst choice.
/me reads quoted message...
Ah right, bionic adds a handler to turn this into an error message, then
doesn't want it to be an error for toybox. Ok then.
It looks like this commit:
commit 483cfdabaf6ab282987a0a21d6177c3daa95dc12
Author: Rob Landley <rob at landley.net>
Date: Sun May 3 20:18:53 2015 -0500
Replace android-specific hack with just signal(SIGPIPE, SIG_IGN).
Got accidentally reverted in:
commit 3b51a07e478d64a84e40b3a7c026b2f8566b194b
Author: Rob Landley <rob at landley.net>
Date: Sun Sep 27 09:03:41 2015 -0500
Another chunk of nommu support, replacing toys.recursion with
toys.stacktop.
Which doesn't even mention SIGPIPE.
That said, SIGDFL is probably better than SIGIGN because we _do_ want it
to kill the process. If we let toybox do the ferror() check on the way
out it could report its own error condition.
> so what about the specific case of ps? (as reported previously,
> desktop ps seems to install a signal handler and _exit(0).)
"Specific case of ps" is a red flag for me, seems like a generic problem
needing a generic solution. The fflush() shenanigans in xprintf() and
xexit() are so this:
$ ./ls -l > /dev/full
ls: write: No space left on device
Gets caught. Not having ps/ls/cat report an error with SIGPIPE seems
similarly generic.
Rob
More information about the Toybox
mailing list