6

The man page for the stdbuf command states that line-buffered mode is invalid as a standard input buffering option. What is the reason for this?

tail -f access.log | stdbuf -iL cut -d' ' -f1 | uniq

stdbuf: line buffering stdin is meaningless
Try `stdbuf --help' for more information.
iruvar
  • 16,725

2 Answers2

9

As the author of stdbuf let me direct you to the "stdio input buffering problems" section at http://www.pixelbeat.org/programming/stdio_buffering/

Pádraig Brady
  • 91
  • 1
    Thank you Padraig, this clarifies to an extent. Having said that, I understand that the input stream is line-buffered by default when connected to a terminal under Linux. Trying to get my head around why stdbuf would not offer this feature. – iruvar Jul 25 '12 at 17:51
  • 6
    The input line buffering you're thinking of happens in the kernel, specifically in the tty driver, not in the program running on the terminal, therefore to control it you don't need stdbuf you only need stty. There is no line buffering of input in the C library. Also I think what you really need in your tail|cut|uniq pipeline is line-buffered output on both tail and cut. – Alan Curry Jul 26 '12 at 04:56
8

Simplified, stdbuf is a wrapper around stdio functionality. Line buffering of input streams is undefined in stdio; I can find no standards document that says what it means, so it is literally meaningless as far as the standards go.

Assuming behavior analogous to stdout line buffering, the line buffering of stdin would require calling read() once for each character read, because there is no other way to guarantee that you don't read past a newline on a descriptor. Since the point of buffering is to reduce the number of system calls, it is unsurprising that the stdio library doesn't implement this.

Kyle Jones
  • 15,015