You may notice that some programs, when run in a shell in
have their output buffered (e.g., people have found this happening to
sql-mode). When the program has a lot of output, it
overflows the buffering and gets printed to the shell buffer; however,
if the program only outputs a small amount of text, it will remain
buffered and won’t appear in the shell buffer. The same can happen
in other subprocesses that themselves run other programs as
subprocesses, for example when using
cvs from Emacs, which
is itself configured to use
ssh, password prompts fail to
appear when expected, and
cvs appears to hang.
Although it may at first seem like the shell is buffering the output from the program, it is actually the program that is buffering output. The C runtime typically decides how to buffer output based upon whether stdout is bound to a handle to a console window or not. If bound to a console window, output is buffered line by line; if bound to a block device, such as a file, output is buffered block by block.
In a shell buffer, stdout is a pipe handle and so is buffered in
blocks. If you would like the buffering behavior of your program to
behave differently, the program itself is going to have to be changed;
you can use
setvbuf to manipulate
the buffering semantics.
Some programs handle this by having an explicit flag to control their buffering behavior, typically -i for interactive, or by a special environment variable. Other programs manage to detect that they are running under Emacs, by using ‘getenv("emacs")’ internally. Look in the program’s documentation for the way around this issue.
|• Perl script buffering|