Re: bin/46021 (xargs should keep still)

[David Holland <dholland-bugs%netbsd.org@localhost>]

The following reply was made to PR bin/46021; it has been noted by GNATS.

From: David Holland <dholland-bugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: bin/46021 (xargs should keep still)
Date: Sun, 6 Jan 2013 23:20:14 +0000

 Please sent PR traffic to gnats-bugs.
 
    ------
 
 From: "James K. Lowden" <jklowden%schemamania.org@localhost>
 To: matthew green <mrg%eterna.com.au@localhost>
 Cc: gnats-admin%netbsd.org@localhost, netbsd-bugs%netbsd.org@localhost, 
dholland%NetBSD.org@localhost
 Subject: Re: bin/46021 (xargs should keep still)
 Date: Sat, 5 Jan 2013 12:27:58 -0500
 
 On Fri, 04 Jan 2013 16:41:10 +1100
 matthew green <mrg%eterna.com.au@localhost> wrote:
 
 > xargs isn't dying because it can't *read* anymore, it's dying
 > because it can't *write* anymore, because eg, "head -3" exited,
 > and then ls gets SIGPIPE when it tries to write more.
 
 Correct.  
 
 > i agree with dh - this isn't a bug.
 
 Well, it's certainly not a feature.  :-)  
 
 I assert no command-line utility should ever report a broken pipe error
 when writing to standard output.  Why?  
 
 1.  It's common for a reader, e.g. head(1), not to read everything.  
 
 2.  There is no mechanism, other than closing the pipe, for the reader
 to notify the writer that it's done.  
 
 Ergo, closing the pipe is *normal*, not an error.  
 
 Although I've never seen it articulated clearly, there is a long, long
 unix tradition of ignoring SIGPIPE on standard output, from arp(1) to
 zcat(1), not to mention ls(1) and cat(1).  The few that I've found that
 don't include xargs, pax, svn, and IIRC git. 
 
 In case the reader is concerned that a genuine error may be missed,
 bear in mind the utility is free to return a nonzero status and the
 shell remains free to interpret it.  Since time immemorial most shells
 I know of have treated the last element in the pipeline as the arbiter
 of the pipeline's success.  I don't see any better choice.  
 
 In the specific instance of xargs, the case is only more obvious
 because xargs is really only plumbing, no more significant on the
 command line than "|" or "``".  It's just an accident of history that
 xargs exists as a utility instead of being part of the shell syntax.  
 
 David left it to me to supply a patch, which I never did.  As I
 understood it at the time, he was skeptical but understood my reasoning
 and was willing to apply a patch of acceptable quality.  
 
 I agree with David that feedback is desirable.  We should have consensus
 on this issue before engaging the compiler.  
 
 --jkl