bug-glibc
[Top][All Lists]
Advanced

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

Re: controlling stdio buffering


From: Pádraig Brady
Subject: Re: controlling stdio buffering
Date: Fri, 24 Mar 2006 09:46:44 +0000
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051013)

Paul Eggert wrote:

>Pádraig Brady <address@hidden> writes:
>
>  
>
>>Paul Eggert wrote:
>>    
>>
>>>If this is merely for debugging, can't you write a wrapper that forces
>>>line buffering for a program?  The wrapper could substitute your own C
>>>library functions via LD_PRELOAD, or could run the program inside a
>>>pseudotty a la 'expect'.
>>>      
>>>
>
>  
>
>>No I was thinking of a more simple general solution,
>>rather than a once off complicated hack.
>>    
>>
>
>But the solution I proposed is general, and would not be a once-off hack.
>It could be packaged up into a program like 'nohup' that could invoke
>any other program.  Such a program (let's call it 'stdiobuf') would be
>easy to use.  It would not require modifying every other utility.
>
>It's much better to have a 'nohup' program, than to add a '--nohup'
>option to every other standard utility.  Similarly, it'd be much
>better to have a 'stdiobuf' program, than to add a '--line-buffer'
>option to every other standard utility.
>  
>
I definitely agree with your sentiment there.
However a seperate program would not give as much control.
It would only make glibc toggle between line buffering and full
buffering on stdout.
That however is all the control I have ever needed to be honest,
so it may be good enough. So more accurately the program should
be called ttyout or something like that.

There is already a script called unbuffer that comes as part of expect,
there are caveats mentioned there however:
http://www.die.net/doc/linux/man/man1/unbuffer.1.html

Sounds like glibc is the right place for this logic
if it needs to be added.

>  
>
>>why does grep have the --line-buffered option for example?
>>    
>>
>
>I don't know; the grep documentation doesn't say much about that
>option.  But the need for the feature in general cannot be all that
>great, if only 'grep' has it now, after all these years of
>development.  And if we can figure out a better way of doing it than
>'grep' does it, we should do it the better way.
>  
>

thanks,
Pádraig.




reply via email to

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