Subject: bug#8961: stdbuf has no effect on some programs

From: Bruno Haible <[email-masked]>
Date: Fri, 1 Jul 2011 11:03:46 +0200

Hi Pádraig,

> Essentially, setting non buffered input is to limit what
> the app reads (so that a subsequent app may further process stdin),
> rather than changing the responsiveness to input.

Oh, really? This ought to be documented and emphasized.

I was under the impression - because "stdbuf -i 0" translates into a
call to setvbuf (stdin, ..., _IONBF) and because the man page of setvbuf
says
     "When an output stream is unbuffered, information
      appears on the destination file or terminal as soon as written"
- that asking for no buffering would also imply immediate responsiveness.

> > Can you name a single program on which -i0 works?
> 
> Programs that use getline() for example (like sed).
> They will change to reading 1 char at a time,
> as will programs that use [f]getc().

I see. So in summary we can say:
  - stdbuf works only on programs that use stdio, because setvbuf calls
    have no effect on the behaviour of read() and write(),
  - If a program only calls [f]getc and processes input immediately,
    then stdbuf -i 0 will have the desired effect (unbuffered input,
    implying no blocking).
  - If a program only calls [f]getc or getline() and processes input
    immediately, then stdbuf -i L will have the desired effect
    (line-buffered input, implying no blocking after a line ends).
  - If a program calls fread() of an entire block, or has logic to call
    [f]getc() until a fixed-size buffer is filled, then stdbuf -i 0
    and stdbuf -i L will have no effect.

Is that right?

Bruno
-- 
In memoriam Karl Gröger <http://en.wikipedia.org/wiki/Karl_Gröger>