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

[enh]

On Mon, Apr 27, 2015 at 9:22 AM, Rich Felker <dalias at libc.org> wrote:
> On Mon, Apr 27, 2015 at 09:17:31AM -0700, enh wrote:
>> On Mon, Apr 27, 2015 at 9:11 AM, Rich Felker <dalias at libc.org> wrote:
>> > On Mon, Apr 27, 2015 at 08:36:53AM -0700, enh wrote:
>> >> On Sun, Apr 26, 2015 at 7:30 PM, Rich Felker <dalias at libc.org> wrote:
>> >> > On Sat, Apr 25, 2015 at 12:14:44PM -0700, enh wrote:
>> >> >> what's the plan wrt SIGPIPE? the desktop is pretty inconsistent. many
>> >> >> (but not all) commands install a signal handler that does _exit(0).
>> >> >> others (coreutils 8.21's ls, say) do nothing. normally "what you do
>> >> >> about SIGPIPE" isn't a problem but on Android that leads to a crash
>> >> >> report and people filing "ls crashed" bugs against me. (our default
>> >> >> shell PS setup is also noisy about crashes.)
>> >> >
>> >> > Why not just *block* SIGPIPE (with sigprocmask) so that the write
>> >> > returns an error (EPIPE) and the program applies the same logic it
>> >> > would for any other write error?
>> >>
>> >> toybox does a little better than toolbox there thanks to xwrite, but
>> >> i've yet never met anyone who checks the return value of printf...
>> >>
>> >> plus there's the question of whether giving up because you're writing
>> >> to a broken pipe is an error exit or not. you could add a special case
>> >> to xwrite (and add xprintf and xputs and...), but since the whole idea
>> >> is that code shouldn't have to care, it's easier just to install a
>> >> signal handler that does _exit(0).
>> >
>> > _exit(0) is wrong and broken. It reports success when the command did
>> > not succeed.
>>
>> coreutils seems divided on this issue.
>
> Could you provide some examples? I think POSIX is pretty clear that
> you can't return success if the output was not successfully written.
> As I already mentioned doing so results in data loss. I really doubt
> coreutils is doing this, but well, GNU software is not always a good
> example of doing the Right Thing...

i did in my original mail.

>> > Failure of the caller to recognize that it didn't succeed
>> > can result in data loss. If anything the right behavior for the signal
>> > handler would be _exit(1) not _exit(0). But I think xwrite/xprintf
>> > solves the issue more elegantly. Note that even if you don't check
>> > every printf, you still get the error status from ferror and/or fflush
>> > at close time (if you check them) but that might result in a lot of
>> > wasted cpu time if you continue processing/writing after a pipe broke.
>>
>> it would also result in things like top(1) not exiting.
>
> If top is using stdio, it's easy to add a single ferror(stdout) check
> to the main loop. If it's using write(), it _must_ be checking for
> errors anyway since write can always return with a short/partial
> write. But top is unlikely to be hooked up to a pipe or socket anyway;
> it normally needs a terminal.

the point is that then people need to think. if that were a plausible
solution, this thread wouldn't exist. the advantage of the signal
handler is that humans can keep on being humans.

-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.

 1430151971.0