I've asked about this on the appropriate bug lists, I think, but have
not receieved a reply. If my interpretation of things is right, this
is about a subtle but somewhat important bug -- and if not, well,
heck, I'd like to be set straight on it so I can adjust my programs
accordingly.
In my opinion, it is incorrect for a shell utility (such as sed or any
of the textutils) to respond to EPIPE for stdout (and, arguably, any
other output file) by
1) printing a message on stderr
2) exiting with non-0 status
The meaning of EPIPE is that the output file in question is a pipe (or
fifo) and that there is no consumer for further output. This is an
ordinary condition that implies only that the utility trying to
produce such output should not produce any further output; in most
cases, such as sed, that means the utility should exit normally.
Under /bin/sh, undesirable behavior results from (1) as when the
the following idiom is used:
if test -z `sed ... | head -1` ; then
...
If one were to use a shell with more flexible monitoring of exit
statuses (such as SCSH and variants), then (2) would also be
problematic. (2) is also problematic in a /bin/sh idiom such as:
( sed ..... && .... ) | head -1
In the event that a true no-reader error occurs, the reader should
exit with non-0 status -- there is no reason for the writer to do so.
Thus, all GNU utils (i.e. this should be a coding convention) should
treat EPIPE specially.
I have found no language in POSIX specs that give guidance one way or
the other.
-t
_______________________________________________
Bug-textutils mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-textutils
