jpm@bnl.UUCP (John McNamee) (11/24/83)
I have a need to pass the input of an interactive program (a BASIC interpreter) thru a filter to block certain characters. I find that if I use a pipe to do the filtering my input is buffered and the interactive nature of the final program is lost (try "cat|mail" to read your mail and you can see what I mean). Given I set up the pipe with "a | b" is there any way for the standard output of "a" to become immediately available on the standard input of "b"? John McNamee uucp: decvax!sbcs!philabs!bnl!jpm arpa: jpm@BNL CompuServe: 70235,1345
per@erix.UUCP (Per Hedeland XT/DU) (11/25/83)
The problem is not the buffering in the pipe, but the buffering done by
the stdio package when standard output isn't a terminal. Provided you
can modify the source code of the filter, the fix is simple. Just insert:
setbuf(stdout, NULL);
before you start writing to stdout; this makes stdout unbuffered.
(BTW, 'cat -u | mail' works (almost) fine.)
Per Hedeland
...{!mcvax}!enea!erix!persuitti@pur-phy.UUCP (Stephen K. Uitti) (11/30/83)
Given I set up the pipe with "a | b" is there any way for the standard output of "a" to become immediately available on the standard input of "b"? Rather than unbuffer the stdio, as was suggested, use fflush() on the pipe when done with a line or message. If only one character is to be processed at a time, maybe unbuffered I/O is what is needed. You will find that unbuffered I/O is SLOW. You do a painful system call for each character. The UN*X kernel really would rather that you send a buch of characters at a time. "fflush" flushes the buffer & waits until the data is written. It should be documented in chapter 3 of the manuals, which we call "c-callable subroutines". Stephen Uitti (Purdue physics site manager) UUCP: pur-ee!Physics:suitti, purdue!Physics:suitti INTERNET: suitti @ pur-phy.UUCP