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