Path: utzoo!attcan!uunet!lll-winken!lll-lcc!ames!ncar!oddjob!mimsy!chris
From: chris@mimsy.UUCP (Chris Torek)
Newsgroups: comp.unix.wizards
Subject: Re: Stdio buffering question
Message-ID: <11914@mimsy.UUCP>
Date: 11 Jun 88 02:42:08 GMT
References: <16124@brl-adm.ARPA> <4999@super.upenn.edu>
Distribution: na
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 37

In article <4999@super.upenn.edu> david@linc.cis.upenn.edu (David Feldman)
writes:
>A self proclaimed novice asked why stderr gets buffered when piped in
>Sun OS 3.3.
>
>Well, I can give an answer based on Ultrix experience.  When piping,
>stderr gets buffered so that it may be separated from stdout.

No.  Buffering is a user-level concept; piping and descriptor
merging is a kernel level concept.  The two are not supposed to
to be mixed together.

Stderr gets buffered because it improves performance and raises
benchmark numbers.  It also makes correct programs fail, and should
not be done casually.

>...  That is assuming you have redirected stderr through the pipe also.
>This is a documented feature, and I believe it is a csh thing.

It has nothing to do with the shell being used.

>I don't think fflush() will help ...

It will.

>...  One way csh could implement this feature is to attach stderr to
>a file and then throw the file down the pipe when stdout closes.

This would generally destroy performance, as the shell would have to
remain in the path of a pipeline.  Currently `a |& b' simply runs a and
b `together' (under csh, a is started first) with a's stdout and stderr
(fds 1 and 2) both going to a pipe that is b's stdin (fd 0).  The
pipe is created with kernel concepts (file descriptors) and the
programs are run without giving them any knowledge as to where those
descriptors connect.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris@mimsy.umd.edu	Path:	uunet!mimsy!chris