tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: why complain about a broken pipe?



> 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

Unless TODO is at least one pipe bufferful in size, this is not a fair
test.  (Not that it matters much; on the systems I have handy, I get
the same result even when using something that _is_ large.)

Also, I'm not sure that even if it is supposed to be noisy that it'd be
cp's job to say anything; arguably cp should just die showing SIGPIPE
(which is what ktrace shows happening in my test) and the shell should
report that.

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

Hm.

I find myself supporting both sides of this now.

Thank you.  I'm now convinced I've never really thought about this
before.

> The general principal is actually quite well established, although
> I've never seen it expressed as such: failure to consume is not an
> error.

I have, though not in this context.  For example, I've seen people
argue forcefully against KNF-style casts to void of calls that return
things on the grounds that it is not an error to ignore a return value.
I'm inclined to agree with them.  (A Linux distro I briefly tried to
use, once, had some of its library routines marked such that ignoring
their return values drew at least a warning.  I didn't like their
choice of calls to apply it to, but I liked drawing a distinction
between calls which return a value it's OK to ignore (eg, printf) and
calls which return a value it's not OK to ignore, at least not without
an explicit indication (eg, getppid).

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

/~\ 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


Home | Main Index | Thread Index | Old Index