Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site sfsup.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!mhuxv!mhuxf!mhuxm!sftig!sfsup!mjs
From: mjs@sfsup.UUCP (M.J.Shannon)
Newsgroups: net.unix-wizards
Subject: Re: Unix standard output buffer problem
Message-ID: <151@sfsup.UUCP>
Date: Mon, 3-Mar-86 13:07:06 EST
Article-I.D.: sfsup.151
Posted: Mon Mar  3 13:07:06 1986
Date-Received: Fri, 7-Mar-86 06:37:21 EST
References: <1421@brl-smoke.ARPA>
Organization: AT&T Information Systems, Summit N.J.
Lines: 33

> 
>    I am looking for a little help in solving a rather interesting problem
> with SYSTEM V Unix.  Here are the symptoms:
> 
> 	I set the standard output flag byte to indicated no buffering:
> 		stdout -> _flag |= _IONBF;  /* Declared in stdio.h */
> 
> 	The code then does a fork() call.  At this point the child and
> 	parent process both report that the stdout -> _flag has the
> 	correct value (I.E. buffering is turned off).
> 
> 	The child process does an exec() type call.  The execed pgm
> 	reports that the stdout -> _flag has mysteriously been reinitialized
> 	to indicate buffering.
> 

First, you shouldn't mess with stdio's flags; to achieve the proper effect, use:
	setbuf(stdout, NULL);
Second, you need to understand what happens when your code executes an exec().
What happens is this: the current process image is abandoned (thrown away) and
a new process image is created (bearing NO relationship to what was there
before the exec() (well, not quite technically true; some kernel data
associated with the process is inherited)).  But, since stdio is not
implemented in the kernel, the new process does its own stdio initialization,
which includes setting up some buffering.
-- 
	Marty Shannon
UUCP:	ihnp4!attunix!mjs
Phone:	+1 (201) 522 6063

Disclaimer: I speak for no one.

"If I never loved, I never would have cried." -- Simon & Garfunkel