Re: why complain about a broken pipe?

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

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

> > 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, [...]
> 
> Actually, I think find and grep should not complain, but the shell
> could reasonably - perhaps optionally - report on their behalf when it
> sees them die showing SIGPIPE.

Thanks for taking the time to push this around, Mouse.  Seems to me
we're in loud agreement, as far as it goes.  You're saying you're fine
with the shell reporting -- i.e. printing -- status termination
messages of pipelined processes.  I am too; the user has his choice of
shell and shell options.  You don't view the shell as a
super-sophisticated process manager.  Nor do I; the practice of
returning the status of only the last process in a pipeline has worked
out pretty well, on the evidence.  

> There are plenty of cases where I _do_ want to hear about SIGPIPE
> deaths

To be clear, I'm talking about standard output exclusively, and more
about EPIPE than SIGPIPE.  pax is basically calling perror

        if (ferror(stdout)) {
                syswarn(1, errno, "Listing incomplete."); 
                break;
        }

before SIGPIPE konks it on the head.  

From what I've found, until ~2006 no NetBSD utility printed
messages about EPIPE when writing to standard output.  Absent clear
argument to the contrary, I'd say those ~40 years of experience should
guide us.  It is our chance to participate in the early delight of
those who reaped the concept from the ashes of Multics.  

Of all the IPC mechanisms, surely the lightest and most ephemeral is
piping standard output to standard input in a shell.  The writing
process commenced on the user's command and was blocked at the user's
command.  By design, the writer cannot know why the reader closed the
pipe.  Therefore the writer can only assume, meekly, that the user
acted with good reason.  With his output blocked, his sole avenue for
complaint is via his exit status, where the shell (or whatever) can
determine what, if anything, should be done.  That's good, too, because
the caller has more contextual information -- interactive shell or not,
background/foreground task, or other options -- on which to base its
decision.  As usual, caller knows best.  

I don't need to explain that greater sophistication, if required, is
afforded by several alternatives.  

I posted my original query because I object to pax (and xargs)
complaining about EPIPE.  I don't see the need.  The script can't
capture it, and the user can see it.  If there *is* a need, I'd like
to know.  Otherwise, I'll submit PRs to remove them, adding by way of
subtracting.  :-)

--jkl