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>
