[Top][All Lists]

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

Re: Possible bug with grep/sed/tail?

From: Paolo Bonzini
Subject: Re: Possible bug with grep/sed/tail?
Date: Tue, 25 Nov 2008 11:34:04 +0100
User-agent: Thunderbird (Macintosh/20081105)

Jim Meyering wrote:
> Paolo Bonzini <address@hidden> wrote:
>>> 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.
>> It would be "+i::o::e::" in getopt parlance; no argument = no buffering,
>> argument is "l" = line buffering, argument is numberic = given-size buffer.
> Hi Paulo,
> When designing new interfaces/tools, it's best to avoid that type of
> optional argument.  This is partly a user interface consistency issue
> (users are used to -il being equivalent to -i -l), and partly that it's
> nonstandard: using "::" like that is a GNU getopt extension.

I was just trying to interpret the specification given in the other
message (not written by me), which I kind of like even though I
understand your point.  The worse problem, I think, is more that users
are used to "-io" being equivalent to "-i -o", and "::" does not support

Instead of "-il" you could use "-i-" for line buffering ("buffer as if
the console was the input", and "-" i.e. stdin is often the console),
but that does not fix the non-standardness of optional arguments and the
fact that "-io" unintuitively does not work.  I still kind of like the
syntax, though.


reply via email to

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