Jim Meyering wrote:
> Paolo Bonzini <[EMAIL PROTECTED]> 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
that.
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.
Paolo
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
