[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