GNU bug report logs - #8961
stdbuf has no effect on some programs

Previous Next

Full log

Message #40 received at 8961 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8961 <at> debbugs.gnu.org
Subject: Re: bug#8961: stdbuf has no effect on some programs
Date: Fri, 01 Jul 2011 10:53:32 +0100

On 01/07/11 10:03, Bruno Haible wrote:
> 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.

All right, except that we disabled -iL as it's ineffective
and would only add more confusion IMHO.

I was going with this patch:

    doc: detail the effect of disabling input buffering with stdbuf

    * docs/coreutils.texi (stdbuf invocation): Expand on the different
    reasons for disabling buffering on input and output.

diff --git a/doc/coreutils.texi b/doc/coreutils.texi
index f74dd1c..ad65cff 100644
--- a/doc/coreutils.texi
+++ b/doc/coreutils.texi
@@ -15437,8 +15437,13 @@ This option is invalid with standard input.

 @item 0
 Disable buffering of the selected stream.
-In this mode data is output immediately and only the
+In this mode, data is output immediately and only the
 amount of data requested is read from input.
+Note the difference in function for input and output.
+Disabling buffering for input will not influence the responsiveness
+or blocking behavior of the stream input functions.
+For example @code{fread} will still block until @code{EOF} or error,
+even if the underlying @code{read} returns less data than requested.

 @item @var{size}
 Specify the size of the buffer to use in fully buffered mode.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.