7.3 Buffering in shells and subprocesses

You may notice that some programs, when run in a shell in shell-mode, have their output buffered (e.g., people have found this happening to them with 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 setbuf and 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