Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 alpha 4/15/85; site elsie.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!panda!talcott!harvard!seismo!elsie!ado
From: ado@elsie.UUCP (Arthur David Olson)
Newsgroups: net.lang.c
Subject: Re: i/o redirection
Message-ID: <5098@elsie.UUCP>
Date: Sat, 20-Apr-85 12:48:15 EST
Article-I.D.: elsie.5098
Posted: Sat Apr 20 12:48:15 1985
Date-Received: Mon, 22-Apr-85 02:19:41 EST
References: <215@ttidca.UUCP> <764@genrad.UUCP>
Organization: NIH-LEC, Bethesda, MD
Lines: 18
Summary: would 'getenv("DONTBUFFER")' do the trick?

In article <215@ttidca.UUCP> davidt@ttidca.UUCP (David Terlinden) writes:
>gsc asks about buffering of stdout of execed processes. . .
>If the flag field in _iob[1] says to buffer output (the default value),
>the first output function to stdout will notice this and allocate a buffer.
>Since _iob is initialized data of the new process, anything you do before the
>exec has no effect.  Can anyone suggest anything other than modifying
>"putchar()" or "_iob[]"?

Here's my wish list solution:  before deciding to buffer output,
standard input/output library functions would check to see if "DONTBUFFER"
(or maybe "BUFFERING=NONE") was present in the environment.  If such a beast
was present, no buferring would be done.

This approach would allow the parent process to control buffering in a way
that was transparent to the child process.
--
	UUCP: ..decvax!seismo!elsie!ado    ARPA: elsie!ado@seismo.ARPA
	DEC, VAX and Elsie are Digital Equipment and Borden trademarks