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

[RG]

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[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