On Mon, Apr 27, 2015 at 9:11 AM, Rich Felker <[email protected]> wrote: > On Mon, Apr 27, 2015 at 08:36:53AM -0700, enh wrote: >> On Sun, Apr 26, 2015 at 7:30 PM, Rich Felker <[email protected]> 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. > 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. -- Elliott Hughes - http://who/enh - http://jessies.org/~enh/ Android native code/tools questions? Mail me/drop by/add me as a reviewer. _______________________________________________ Toybox mailing list [email protected] http://lists.landley.net/listinfo.cgi/toybox-landley.net
