Path: utzoo!utgpu!watserv1!watmath!att!mcdchg!laidbak!ism.isc.com!uunet!know!zaphod.mps.ohio-state.edu!julius.cs.uiuc.edu!apple!olivea!orc!inews!cmdnfs!bhoughto
From: bhoughto@cmdnfs.intel.com (Blair P. Houghton)
Newsgroups: comp.unix.shell
Subject: Re: Output redirection
Message-ID: <520@inews.intel.com>
Date: 19 Oct 90 16:28:51 GMT
References: <3447@idunno.Princeton.EDU> <15479@hydra.gatech.EDU>
Sender: news@inews.intel.com
Organization: Intel Corp, Chandler, AZ
Lines: 22

In article <15479@hydra.gatech.EDU> gt0178a@prism.gatech.EDU (Jim Burns) writes:
>in article <3447@idunno.Princeton.EDU>, pfalstad@phoenix.Princeton.EDU (Paul John Falstad) adds:
>
>> 	setlinebuf(stdout);  /* this should fix it */
>
>to Abhay B. Joshi's c code. Let's assume a situation where you don't have
>the source code. How would you synchronize output only thru shell
>mechanisms?

You wouldn't.  The shell has no control over buffering
done by binary executables.  setlinebuf() in the c code
is more certain.  Abhay apparently thought the newlines
would force a buffer-flushing; setlinebuf() fixed the
program to fit that concept.

If you want the output completely unbuffered (which hogs CPU
and I/O resources if you are using it with functions that
write more than one char at a time) use setbuf(stdout,NULL)
and setbuf(stderr,NULL).

				--Blair
				  "setbuf(usenet,NULL,apparently...)"