Line-by-line processing when stdin is not a tty

Thu Aug 12 03:49:26 CEST 2010

In article <pan.2010. at>,
 Nobody <nobody at> wrote:

> On Wed, 11 Aug 2010 10:32:41 +0000, Tim Harig wrote:
> >>> Usually you either
> >>> need an option on the upstream program to tell it to line
> >>> buffer explicitly
> >>
> >> once cat had an option -u doing exactly that but nowadays
> >> -u seems to be ignored
> >>
> >>
> > 
> > I have to wonder why cat knows or cares.
> The issue relates to the standard C library. By convention[1], stdin and
> stdout are line-buffered if the descriptor refers to a tty, and are
> block-buffered otherwise. stderr is always unbuffered.
> Any program which uses stdin and stdout without explicitly setting the
> buffering or using fflush() will exhibit this behaviour.
> [1] ANSI/ISO C is less specific; C99, 7.19.3p7:
> 	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.
> POSIX says essentially the same thing:
> <>

This doesn't explain why "cat | cat" when run interactively outputs 
line-by-line (which it does).  STDIN to the first cat is a TTY, but the 
second one isn't.

For that matter, you can also do this:

nc -l 1234 | cat

and then telnet localhost 1234 and type at it, and it still works 


More information about the Python-list mailing list