Path: utzoo!attcan!uunet!mcvax!hp4nl!phigate!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.unix.questions
Subject: Re: RTFM... (really: sed -n 100,115p)
Message-ID: <1037@philmds.UUCP>
Date: 22 May 89 06:14:46 GMT
References: <2859@buengc.BU.EDU> <611213677.29680@ontmoh.UUCP> <1031@philmds.UUCP> <7298@bsu-cs.bsu.edu> <1033@philmds.UUCP> <7320@bsu-cs.bsu.edu>
Reply-To: leo@philmds.UUCP (Leo de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 40

In article <7320@bsu-cs.bsu.edu> dhesi@bsu-cs.bsu.edu (Rahul Dhesi) writes:
|In article <1033@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
|>Are you
|>implying that each filter should read all its input ??
|
|Yes, unless it knows that a process providing that input is prepared to
|gracefully handle the situation when writing to stdout causes an
|error.  From the user's point of view,
|
|     % mypgm | myfilter
|     ... output from myfilter ...
|     mypgm: error writing to stdout: broken pipe
|     %
|
|is not a friendly situation, because it makes it seem that something
|went wrong.  Compare this with:
|
|     % mypgm | myfilter
|     ... output from myfilter ...
|     %

Unless mypgm catches SIGPIPE and tries to be clever about writing to
stdout, the first situation will not occur. Note that the default
setting for SIGPIPE will cause that process to be terminated. I would
call a program that did
     mypgm: error writing to stdout: broken pipe
broken, or at least unable to treat this gracefully. The problem is in
the input filter, not in the output filter that decides it has read
enough.  The correct treatment of SIGPIPE is to cleanup, then exit.
Since many simple filters even don't need to cleanup (e.g. remove tmp
files), they don't bother to catch the signal; the default action is
sufficient.

B.T.W Try mypgm | more , then hit 'q' at the first --More-- prompt.
Are you going to complain about more getting its I/O wrong when you
get
     mypgm: error writing to stdout: broken pipe
?

	  Leo.