bug-coreutils
[Top][All Lists]
Advanced

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

Re: Possible bug with grep/sed/tail?


From: Pádraig Brady
Subject: Re: Possible bug with grep/sed/tail?
Date: Tue, 25 Nov 2008 10:51:46 +0000
User-agent: Thunderbird 2.0.0.6 (X11/20071008)

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

Note -o would require an arg so it's unambiguous.
It's like `ls -w2` working and `ls -w -2` giving an error.

Perhaps it's a policy for lower case parameters
in case -l would ever be needed in future?
In that case would requiring a capital L as a parameter suffice?

> , 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)

I'm conscious of making the modifier as unobtrusive as possible.
If we really need to use long options then could we just use:

stdbuf --o=L
stdbuf --i=4096 --o=8192

thanks,
Pádraig.




reply via email to

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