The first problem is that readlines reads all the lines in the list. He cannot do this until all lines are present, which will not be until stdin reaches EOF.
But actually you do not need a list of lines, but just a few lines. And a file like sys.stdin is already so iterable. And it's lazy that generates one row at a time as soon as they are available, instead of waiting to generate them all at once.
So:
for line in sys.stdin: print line
Whenever you find yourself readlines , ask yourself if you really need it. The answer will always be negative. (Well, except when you want to call it with an argument or on some defective object other than a file.) See Readlines, which is considered silly for more.
But meanwhile, there is a second problem. Itβs not that Python is buffering its stdin or that another process is buffering its stdout , but the file object iterator itself is doing internal buffering, which may (depending on your platform, but on most POSIX platforms, it usually will prevent you from getting there until the first line before EOF, or at least until many lines are read.
This is a known issue with Python 2.x, which was fixed in 3.x, * but it will not help you if you do not want to upgrade.
The solution is mentioned in the command line and environment documents and in the man page of most systems, but the documentation is buried in the middle of -u flag :
Note that inside xreadlines (), readlines (), and file and object iterators, there is internal buffering ("for a line in sys.stdin") that is not affected by this option. To get around this, you will want to use "sys.stdin.readline ()" inside the "1:" loop.
In other words:
while True: line = sys.stdin.readline() if not line: break print line
Or:
for line in iter(sys.stdin.readline, ''): print line
For another problem, in this answer , Alex Martelli points out that you can always just ignore the sys.stdin and rec fdopen file descriptor. This means that you get a wrapper around POSIX fd instead of the C stdio handle. But this is neither necessary nor sufficient for this question, because the problem is not with C stdio buffering, but with how file.__iter__ buffering interacts with it.
* Python 3.x no longer uses the Stdio library buffering; it does everything on its own in io types, which means that the iterator can simply use the same buffer, the file itself using the file. Although io is also available on 2.x, this is not the standard thing you get for open or for file descriptors stdio, so this does not help here.