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 13 years and 326 days ago.

Previous Next


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