Unix standard output buffer problem

PUPPY%clemson.csnet at csnet-relay.arpa PUPPY%clemson.csnet at csnet-relay.arpa
Sat Mar 1 10:30:19 AEST 1986


   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.

  I have checked the C run-time startup routines (crt0.c) and it does not
appear to mess with this flag setting.

  I have check the printf code and it does not harm the flag as best I 
could tell.
  
 I have checked the exec source and it does not appear to mess with it either.

 I have checked the kernel's expand () source (exec does an expand) and it
to does'nt seem to do anything with this flag setting.

 
 My problem is that I need to turn off this buffering so that the execed
program has buffering initially turned off.  Because of the nature of the
application I cannot use stty's or ioctl's to accomplish this. This problem
is also an annoyance if one trys to set up a pipe to a program (such
as mail) to work with its standard input and output. (Mailx will put
"Command?" into the pipe but because of buffering the parent process will
not receive this because there is no \n in the prompt).  I have found
this problem to be on a VAX 11/780 running Ultrix, several NCR Towers and
a Perkin Elmer 3200 running Xelos.  I would appreciate any help you could
be in locating the source of the problem as well as any suggestions on
how to correct or circumvent the problem.

Please send responses directly to:  puppy at clemson.csnet

William Faulkner

has experienced this problem



More information about the Comp.unix.wizards mailing list