Re: why complain about a broken pipe?

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

On Sun, 5 Feb 2012 12:47:51 -0500 (EST)
Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> > The shell reports the return status only of the last process in a
> > pipeline.
> 
> Depends on the shell and the status.  I find, on 4.0.1, that sh and
> csh each report status of non-last processes which die on SIGQUIT, and
> presumably at least some other conditions (though if it's foregrounded
> at the time, csh doesn't say _which_ process suffered).

I'm not sure what you mean.  

$ yes | grep . | cat  > /dev/null && echo OK&
$ pkill grep 
[1]   Broken pipe             yes |
      Terminated              grep . |
      Done                    cat >/dev/null
OK

I see the shell printing messages about the exit status of each process.
I do not see a way to act on yes's return status in a shell script.  The
pipeline still prints "OK".  

I was prompted offline for a more idiomatic example.  

        $ find /usr | xargs ls -F | grep / | head -2
        /usr/X11R7/bin/X@
        /usr/X11R7/bin/Xmark*
        xargs: ls terminated by SIGPIPE

xargs?  Not find or grep or ls?  xargs *on behalf of* ls?  

As recently as 2006 (rev 1.15) our xargs didn't peep about exit
status unless it was 255.  The above message seems to have arrived with
the FreeBSD version.  

I know: it's a trend.  One might suggest that talking too much is a
trend in the *culture*.  I know there were debates way back when about
whether or not rm(1) should print an error message if the file isn't
found because, after all, deleting a file -- extant or not -- achieves
the same result.  But at least there was a debate, with two plausible
sides.  

I don't see any reason to report errors writing to standard output.  If
there were one, all four utilities in my example would have complained,
and we all would have switched to another computing facility 35 years
ago.  

--jkl