Re: why complain about a broken pipe?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Thanks for taking the time to push this around, Mouse.

Thanks for bringing it up.  It's not something I'd previously really
given any thought to.  I'm still not sure what I think the right thing
is in some cases, but I'm at least aware of some of the issues!

> Seems to me we're in loud agreement, as far as it goes.

Well...on some points (as you say).  Less so on others.  And there are
cases - such as xargs - where I'm fairly sure there is nothing I would
say is a right answer that's implementable within the current paradigm.
So far I haven't come up with anything better, though, so I haven't
brought it up at all.

> [T]he practice of returning the status of only the last process in a
> pipeline has worked out pretty well, on the evidence.

Well...I'm not sure I'd count silent acquiescence as implying "pretty
well".  It's worked out well enough that nobody with the ability has
been moved to change it, nor have those without the ability kicked up a
fuss over it.  I'm not sure I'd say that implies it's worked out any
better than "tolerably".

>> 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.

Well, if you don't have SIGPIPE ignored, caught, or blocked, you don't
last long enough to even _get_ EPIPE, so in general only SIGPIPE-aware
programs ever see EPIPE at all.  ("In general" because it's possible to
ignore or block SIGPIPE and then exec another program; also, when
writing to sockets, use of send()-family calls with MSG_NOSIGNAL can
produce EPIPE without SIGPIPE.  That's not usual for vanilla stdout,
though.)

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

This actually makes sense.  To use tar command-lines instead because I
don't know pax well enough, I think "tar tvf foo.tar > bar.list"
_should_ produce something like this if, say, stdio sees ENOSPC.
Producing it in the case of EPIPE as well is, I think, just a side
effect, an interaction of that code with not dying on SIGPIPE.  I'm
inclined to say the right fix here is not to remove the test and
warning, but to stop doing anything special with SIGPIPE...at least
until and unless someone can come up with a convincing reason why it's
necessary to mess with SIGPIPE.

> 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,

Actually, scripts _can_ capture it.  stderr can be redirected.

Unless it writes to /dev/tty, in which case I agree it needs fixing
yesterday.  The only output I've ever seen that I think deserves to be
written directly to /dev/tty is SIGINFO output, and even that I'm not
sure of - I think the desire SIGINFO was invented to address can be
addressed much better other ways.  I'm just not sure what those other
ways are yet; I have a few ideas, but nothing defniite enough to have
even hacked together an experiment.

> 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.  :-)

Well, I'm certainly not opposed to adding by way of subtracting; I'm
firmly in Saint-Exupery's camp there.  I think my stance on pax is
covered above by my remarks.  xargs I'm not sure what to do about; I
don't think it's possible to get that one right without significantly
extending the concept of a shell.  xargs is, if you will, acting as a
(severely special-case) shell in that it's running other user-specified
processes; as such, it's well within its bailiwick to report on
abnormal terminations.  The problem, of course, is that the user's
choice of shell and/or configuration does not apply to xargs.  (For
that matter, this also leads into my rants about users not being able
to set arbitrary shells, thanks to a disastrous API design mistake many
years ago.)  I'm not sure how to fix xargs; I'm not even sure it should
be fixed (as opposed to thrown out and replaced).  But, fix or replace,
I don't have anything to suggest at the moment which I think is any
better.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B