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

Previous Next

Package: coreutils;

Reported by: Bruno Haible <bruno <at> clisp.org>

Date: Wed, 29 Jun 2011 21:00:03 UTC

Severity: normal

Done: Pádraig Brady <P <at> draigBrady.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Pádraig Brady <P <at> draigBrady.com>
To: Bruno Haible <bruno <at> clisp.org>
Cc: 8961 <at> debbugs.gnu.org
Subject: bug#8961: stdbuf has no effect on some programs
Date: Thu, 30 Jun 2011 14:52:20 +0100
On 30/06/11 00:34, Bruno Haible wrote:
> Hi Pádraig,
> 
>> The following shows I think that iconv is bypassing stdio and buffering internally?
>>
>> (echo; sleep 3; echo) | ltrace iconv -f ASCII
> 
> Indeed, the glibc 'iconv' does not use stdio apparently:
> 
> __libc_start_main(0x402a00, 3, 0x7fff76b92d68, 0x409c90, 0x409c80 <unfinished ...>
> setlocale(6, "")                                                                                 = "de_DE.UTF-8"
> textdomain("libc")                                                                               = "libc"
> argp_parse(0x60d2e0, 3, 0x7fff76b92d68, 0, 0x7fff76b92c5c)                                       = 0
> strchr("ASCII", '/')                                                                             = NULL
> strchr("", '/')                                                                                  = NULL
> iconv_open(0x409daf, 0x7fff76b946e6, 0, 0x53494c4300494900, 0xfefefefefefefeff)                  = 0x613080
> fileno(0x7f4c6e9726a0)                                                                           = 0
> realloc(NULL, 32768)                                                                             = 0x00615100
> read(0, "\n", 32768)                                                                             = 1
> read(0, "\n", 32767)                                                                             = 1
> read(0, "", 32766)                                                                               = 0
> iconv(0x613080, 0x7fff76b8ab38, 0x7fff76b8ab30, 0x7fff76b92b48, 0x7fff76b92b40)                  = 0
> ...
> 
>> The stdbuf man page notes that:
>>
>> NOTE: If COMMAND adjusts the buffering of its standard  streams  (`tee'
>> does  for  e.g.) then that will override corresponding settings changed
>> by `stdbuf'.  Also some filters (like `dd' and `cat'  etc.)  don't  use
>> streams for I/O, and are thus unaffected by `stdbuf' settings.
> 
> This paragraph is written in a way that does not make the implications
> very clear. How about the attached patch, meant to show the restrictions more
> prominently?
> 
> 
> 2011-06-29  Bruno Haible  <bruno <at> clisp.org>
> 
> 	* doc/coreutils.texi (stdbuf invocation): Mention the restrictions on
> 	the command more prominently.
> 
> --- doc/coreutils.texi.orig	Thu Jun 30 01:31:13 2011
> +++ doc/coreutils.texi	Thu Jun 30 01:30:54 2011
> @@ -15398,6 +15398,17 @@
>  stdbuf @var{option}@dots{} @var{command}
>  @end example
>  
> +@var{command} must start with the name of a program that
> +@enumerate
> +@item
> +uses the ISO C @code{FILE} streams for input/output (note the
> +programs @command{dd} and @command{cat} don't do that),
> +
> +@item
> +does not adjust the buffering of its standard streams (note the
> +program @command{tee} is not in this category).
> +@end enumerate

I'll apply this.
I'll might also add a note about fread() blocking (which POSIX requires)
and that setting no _buffering_ doesn't impact that.

cheers,
Pádraig.




This bug report was last modified 14 years and 9 days ago.

Previous Next


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