Re: Possible bug with grep/sed/tail?

[Pádraig Brady]

Jim Meyering wrote:
> Pádraig Brady <address@hidden> wrote:
>> Jim Meyering wrote:
>>>> What about adding buffer control to all coretuils filters.
>>>> Is that still a desired feature do you think?
>>> I don't relish the idea of adding an option or feature
>>> to each and every filter in coreutils.  Especially
>>> considering that this approach solves the problem --
>>> albeit with requirement on gcc and LD_PRELOAD.
>>> Maybe we can relax that requirement...
>> A general tool would be much better than adding options
>> to all filters, hence why I originally asked to have this
>> added to glibc.
>>
>> I wonder would it be useful to have a "Modified command invocation"
>> command that set the LD_PRELOAD environment variable to point
>> to a lib installed, and also set other environment variables
>> to control the buffering depending on command line options.
>>
>> For example if we called the command stdbuf, then
>> the following pipeline would be line buffered:
>>
>> tail -f access.log | stdbuf --fd=1 --size=1 cut -d' ' -f1 | uniq
>>
>> size=0 => unbuffered
>> size=1 => line buffered
>> size>1 -> specific buffer size
>>
>> Also we could have aliases for stdin stdout, linebuffered, ...
>>
>> We still have the requirement on LD_PRELOAD, but
>> that's not too bad I think?
> 
> I like that.  The "stdbuf" name sounds fine, too.
> Though maybe use --size=-1 to indicate line buffering,
> (or even a separate --line-buffered option),
> rather than usurping --size=1.
> 
> Sounds like you've just volunteered ;-)

Um Ok so :)

Thinking a little more about it, the interface above
is probably a little too general.

I'm now thinking of 3 options: stdbuf -i -o -e
The usual use case is: stdbuf -ol
But you could also do: stdbuf -i4096 -o8192
We would warn about redundant combos like: stdbuf -il

Pádraig.