Difference in buffering of stdout on Linux and Windows

Assuming you're talking about CPython (likely), this has to do with the behaviour of the underlying C implementations.

The ISO C standard mentions (C11 7.21.3 Files /3) three modes:

• unbuffered (characters appear as soon as possible);
• fully buffered (characters appear when the buffer is full); and
• line buffered (characters appear on newline output).

There are other triggers that cause the characters to appear (such as buffer filling up even if no newline is output, requesting input under some circumstances, or closing the stream) but they're not important in the context of your question.

What is important is 7.21.3 Files /7 in that same standard:

As initially opened, the standard error stream is not fully buffered; the standard input and standard output streams are fully buffered if and only if the stream can be determined not to refer to an interactive device.

Note the wiggle room there. Standard output can either be line buffered or unbuffered unless the implementation knows for sure it's not an interactive device.

In this case (the console), it is an interactive device so the implementation is not permitted to use unbuffered. It is, however allowed to select either of the other two modes which is why you're seeing the difference.

Unbuffered output would see the messages appear as soon as you output them (a la your Windows behaviour). Line-buffered would delay until output of a newline character (your Linux behaviour).

If you really want to ensure your messages are flushed regardless of mode, just flush them yourself:

import time, sysfor i in xrange(10):    time.sleep(1)    print "Working",    sys.stdout.flush()print

In terms of guaranteeing that output will be buffered when redirecting to a file, that would be covered in the quotes from the standard I've already shown. If the stream can be determined to be using a non-interactive device, it will be fully buffered. That's not an absolute guarantee since it doesn't state how that's determined but I'd be surprised if any implementation couldn't figure that out.

In any case, you can test specific implementations just by redirecting the output and monitoring the file to see if it flushes once per output or at the end.

The behavior differs because the buffering is generally unspecified, which means implementations can do whatever they want. And, it means that implementations can change at any time, or vary in undocumented ways, possibly even on the same platform.

For example, if you print a "long enough" string on Linux, with no newline (\n), it will likely be written through as if it had a newline (because it exceeds the buffer). You may also find the buffer size varies between stdout, pipes, and files.

It's really bad to depend on unspecified behavior, so use flush() when you really need the bytes to be written.

And if you need to control buffering (e.g. for performance reasons), then you need to implement your own buffering on top of write() and flush(). It's pretty straightforward to do, and that gives you complete control over how and when bytes are actually written.

Windows and Linux have very different console output drivers. In Linux, the output is being buffered until the \n occurs in the case of your program.

If you want to force the buffer to flush manually use

import syssys.stdout.flush()