Paolo Bonzini wrote:
> 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.
-o- is a neat suggestion to mean line buffering.
However it's ambiguous as stdin and stderr are not line buffered
when connected to a terminal.
Pádraig.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
