[Top][All Lists]

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

Re: Possible bug with grep/sed/tail?

From: Jim Meyering
Subject: Re: Possible bug with grep/sed/tail?
Date: Tue, 25 Nov 2008 10:45:58 +0100

Pádraig Brady <address@hidden> wrote:
>>> 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

So -ol (that's an el) would mean line-buffered stdout?
That has to be equivalent to -o -l, and unless you consider
ordering and multiple -l options (e.g., "-i -l -o -l" is ugly),
then it doesn't let you line-buffer more than one of the three streams.

How about making -i -o -e mean line-buffered (--input --output --error),
and -I N -O N -E N specify the less-common cases of no buffering
or an N-byte buffer size? (--i-buf=N --o-buf=N --e-buf=N)

reply via email to

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