Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site umcp-cs.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!ll-xn!topaz!lll-crg!gymble!umcp-cs!chris
From: chris@umcp-cs.UUCP (Chris Torek)
Newsgroups: net.unix
Subject: Re:  tee command without buffering
Message-ID: <2530@umcp-cs.UUCP>
Date: Wed, 11-Dec-85 19:13:30 EST
Article-I.D.: umcp-cs.2530
Posted: Wed Dec 11 19:13:30 1985
Date-Received: Fri, 13-Dec-85 08:52:24 EST
References: <509@brl-tgr.ARPA>
Organization: U of Maryland, Computer Science Dept., College Park, MD
Lines: 22

In article <509@brl-tgr.ARPA> kvancamp@ardc.arpa (LCWSL) writes:

> The fourth reply I got was from someone who said that what I wanted
> [`stopping buffering of the tee command'] is impossible because
> the buffering is inherent in the system (i.e., it isn't the fault
> of tee because tee already works on only one byte at a time).

Close.  The problem is not in tee, but neither is it in the system:
It is in the command you are using on the left hand side of the
pipe.  Most standard I/O libraries automatically line buffer file
output if the file itself is a terminal, and block buffer the output
otherwise.  A careful program will use `fflush' at appropriate
points; indeed, I find that the `helpful' line buffering is
unnecessary and even problematical at times.

If a program behaves differently---aside of course from speed---when
its output is run through an unbuffered `cat'-like filter (e.g.,
`tee /dev/null'), it is not well written.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris@mimsy.umd.edu