Unix standard output buffer problem

[Joseph S. D. Yao]

In article <1421 at brl-smoke.ARPA> PUPPY%clemson.csnet at csnet-relay.arpa writes:
>	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.  ...
>	The child process does an exec() type call.  The execed pgm
>	reports that the stdout -> _flag has mysteriously been reinitialized
>	to indicate buffering.

The problem is, that local states aren't carried over in an exec().
When a program is exec'ed, the entire memory of the process being
run is wiped clean, and then the image of the new program is overlaid
on top of it.  So, you see, unfortunately, no status information can
be passed down except via command-line arguments or other, non-
standard techniques (like using IPC's: pipes, sockets, shared memory,
mailboxes, et alii).

Stdout is always unbuffered if and only if it is connected to a tty;
otherwise it defaults to buffered.  You may set it to unbuffered for
the duration of your program with setbuf(stdout, (char *) NULL); but
this does not last past exec()'s.  You may alternatively (and should,
if leaving stdout buffered) do an fflush(stdout) every time that you
think you want output to appear.  This, unfortunately, doesn't help
you if what you want to do is run a binary program thorugh a pipe.
There were, once upon a time, various kernel mods to associate a
pipe with a tty, so that stat's and ioctl's got passed through.  I'm
afraid I don't have any references here and now.

BTW:  for future reference, the stdio routines are given to you so
that you don't have to mess with FILE internals.  Don't do it: it'll
turn around and bite you some day when you least expect it ...
-- 

	Joe Yao		hadron!jsdy at seismo.{CSS.GOV,ARPA,UUCP}