bug-coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#8961: stdbuf has no effect on some programs


From: Bruno Haible
Subject: bug#8961: stdbuf has no effect on some programs
Date: Thu, 30 Jun 2011 01:34:12 +0200
User-agent: KMail/1.9.9

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  <address@hidden>

        * 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 @address@hidden @var{command}
 @end example
 
address@hidden must start with the name of a program that
address@hidden
address@hidden
+uses the ISO C @code{FILE} streams for input/output (note the
+programs @command{dd} and @command{cat} don't do that),
+
address@hidden
+does not adjust the buffering of its standard streams (note the
+program @command{tee} is not in this category).
address@hidden enumerate
+
 Any additional @var{arg}s are passed as additional arguments to the
 @var{command}.
 
@@ -15446,12 +15457,6 @@
 
 @end table
 
-NOTE: If @var{command} adjusts the buffering of its standard streams
-(@command{tee} does for e.g.) then that will override corresponding settings
-changed by @command{stdbuf}.  Also some filters (like @command{dd} and
address@hidden etc.) don't use streams for I/O, and are thus unaffected
-by @command{stdbuf} settings.
-
 @cindex exit status of @command{stdbuf}
 Exit status:
 
-- 
In memoriam José Olaya <http://es.wikipedia.org/wiki/José_Olaya>





reply via email to

[Prev in Thread] Current Thread [Next in Thread]