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

[enh]

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.

so what about the specific case of ps? (as reported previously,
desktop ps seems to install a signal handler and _exit(0).)

On Wed, Jun 10, 2015 at 11:23 AM, Rob Landley <rob at landley.net> 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?
>
> Rob



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