Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!umd5!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: comp.unix.wizards
Subject: Re: Stdio buffering question
Message-ID: <8076@brl-smoke.ARPA>
Date: 11 Jun 88 09:56:53 GMT
References: <16124@brl-adm.ARPA> <4999@super.upenn.edu>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Distribution: na
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 19

In article <4999@super.upenn.edu> david@linc.cis.upenn.edu.UUCP (David Feldman) writes:
>Well, I can give an answer based on Ultrix experience.  When piping,
>stderr gets buffered so that it may be separated from stdout.  Stdout
>goes through the pipe, and when it is closed, the stderr buffer gets flushed
>through the pipe.  That is assuming you have redirected stderr through the
>pipe also.   This is a documented feature, and I believe it is a csh thing.

What the hell are you talking about?  The whole reason for the invention
of the standard error output as distinct from standard output is to AVOID
error output getting mixed with legitimate output in pipelines etc.

I don't like csh, but I won't accuse it of directing standard error output
into pipes.  Indeed I think you'd have to work fairly hard to get it to
do so.

My guess for the reason that stderr is (line-)buffered on some BSD-derived
systems is that Bill Shannon once thought it would be a good idea and just
did it.  (Apologies if I'm maligning him.)  It is also possible that
someone thought it would improve network performance for error output to
be sent in large chunks rather than a character at a time.