[Toybox] default SIGPIPE handler that calls _exit(0)?

[Rich Felker]

On Wed, Jun 10, 2015 at 01:23:07PM -0500, Rob Landley wrote:
> On 05/03/2015 03:53 PM, enh wrote:
> > On Sat, May 2, 2015 at 1:32 PM, Rich Felker <dalias at libc.org> wrote:
> >> On Sat, May 02, 2015 at 12:04:31PM -0700, enh wrote:
> >>>> Sure, outside toybox yay sigpipe. But inside, the question is what the
> >>>> correct behavior should be.
> >>>>
> >>>> It sounds like android wants _exit(0)
> >>>
> >>> no, not particularly. we're arguing internally about whether SIGPIPE
> >>> is a crash or not. i think even undoing the dynamic linker's
> >>> installation of a crash reporter by setting it back to SIG_DFL would
> >>> be fine for toybox --- the real problem is that the dynamic linker
> >>> doesn't know whether it's dealing with an Android app (where you
> >>> probably do want the crash reporting) or a command-line tool (where
> >>> you probably don't), let alone corner cases like a command-line tool
> >>> that's implemented in Java.
> >>
> >> In that case the crash-reporting signal handler setup should be in the
> >> Android app init code, not the dynamic linker, no?
> > 
> > there are a large number of native-only daemons running on the average
> > Android device, most of which we only see as binary blobs.
> 
> I have a todo item here, the posix guys have been proposing adding set
> -o pipefail and doing their usual insane bikeshedding where "yes | head"
> should always exit failure because yes couldn't successfully write all
> its (infinite) output. Meanwhile head discarding input is what head is
> _for_...
> 
> http://austingroupbugs.net/view.php?id=789
> 
> Not sure what the right answer is, error return-wise. The android
> approach is to return success when terminating output due to -EPIPE (as
> opposed to -ENOSPC or other errors), and I'm pretty happy to do the
> same... assuming I can figure out how to beat the error out of ferror().
> (You record that there _was_ an error, but not the errno. So I was
> happily doing printf(), printf(), printf(), and then fflush() and
> ferror() and if the earlier printf returned an errno you ate it and
> didn't save it for me thank you very much...)
> 
> Anyway, opinions on this?

The problem with your reasoning is that the program writing to the
pipe cannot know it's piping to head or something that wants to throw
away input. Since it doesn't know, it _must_ exit with failure when
all output could not be written.

The 'yes' command is something of a stupid special case and nobody
should really care what it exits with; it's not even standard. But
something like 'sed' really needs to report write errors. Anything
else could lead to data loss. You can't say "EPIPE is special but I'm
going to report errors on ENOSPC" because the EPIPE could be _caused_
by ENOSPC in the command you're piping to, e.g.

sed s/a/b/g < foo.txt | tr -d c > out.txt && mv out.txt foo.txt

In the above example, the error status from tr will prevent mv from
running, but now consider something like:

sed s/a/b/g < foo.txt > my_fifo && rm foo.txt

Another example is running a command directly connected to a socket,
e.g. from inetd. If the socket breaks, you get EPIPE, and that needs
to be treated as an error that the calling script sees, not as
successful exit.

Rich

 1433963404.0