In article <pan.2010.08.12.00.42.26.343...@nowhere.com>, Nobody <nob...@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[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: > > <http://www.opengroup.org/onlinepubs/9699919799/functions/stdin.html> 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 line-by-line. rg -- http://mail.python.org/mailman/listinfo/python-list