Re: why complain about a broken pipe?

["James K. Lowden" <jklowden%schemamania.org@localhost>]

On Sat, 4 Feb 2012 18:56:19 -0500 (EST)
Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> > It is normal for readers of pipes to close them before EOF,
> 
> Is it?  That's not my perception.  I can think of only three cases in
> which I've commonly had programs close pipes before reading EOF:
> head(1), my tar (which is arguably a bug), and cases like dd being
> specifically told to read only a certain amount.

It is absolutely normal.  Not only is it normal, it's neccessary!  

"sed 1q" would do it, or awk. Any filter capable of stopping based on a
condition, e.g.  N lines, or regex match.  

It's fairly common to type something like "man pax" and read part of
the text.  $PAGER need not read the whole output from groff; it
would be a nuisance to see "broken pipe" simply for pressing 'q'.  

pax is the only utility in base I can find that produces an error
message if standard output is closed.  cat(1) and cp(1) do not
complain e.g., 

        $ cp TODO /dev/stdout | head -1
        Big features

Neither do find(1) or ls(1).  Surely whether or not cp completes its
job is more important than whether or not pax finishes listing its
toc.  

The general principal is actually quite well established, although I've
never seen it expressed as such: failure to consume is not an error.
Only the reader knows if it's satisfied.  True, it may not be aware that
the writer aborted, but if that matters the data must be structured such
that the reader knows they're incomplete.  

> The user can perfectly well see what happened and
> > always has the option of testing the return status.
> 
> The user can't always see what happened; there not even be any "the
> user".  

The shell reports the return status only of the last process in a
pipeline.  What use is splatting a message to stderr if no programmatic
action is possible?  

CSV shows this message was added to pax in revision 1.32 back in 2004 by
Christos from a patch supplied by Greg A. Woods as part of PR bin/27213
(http://mail-index.netbsd.org/netbsd-bugs/2004/10/10/0007.html).  The
PR was well founded: pax kept on processing even if standard output was
closed.  The patch fixed that problem, and all was well, almost.  I
propose the following improvement.  It will remove noise, in equal
measures, from stderr and from this list.  ;-)

Index: ar_subs.c
===================================================================
RCS file: /cvsroot/src/bin/pax/ar_subs.c,v
retrieving revision 1.56
diff -u -r1.56 ar_subs.c
--- ar_subs.c   31 Aug 2011 16:24:54 -0000      1.56
+++ ar_subs.c   5 Feb 2012 15:46:25 -0000
@@ -260,7 +260,8 @@
                         * has been closed by the reader.
                         */
                        if (ferror(stdout)) {
-                               syswarn(1, errno, "Listing
incomplete.");
+                               if (vflag)
+                                       syswarn(1, errno, "Listing
incomplete."); 
                                break;
                        }

My preference would be to delete the syswarn line, but I expect hiding
it inside verbose mode has a better chance of acceptance.  

--jkl