Line-by-line processing when stdin is not a tty
rNOSPAMon at flownet.com
Thu Aug 12 03:49:26 CEST 2010
In article <pan.2010.08.12.00.42.26.343000 at nowhere.com>,
Nobody <nobody at nowhere.com> 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
> >> http://www.opengroup.org/onlinepubs/009695399/utilities/cat.html
> > I have to wonder why cat knows or cares.
> The issue relates to the standard C library. By convention, 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.
>  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