Bo Borgerson wrote:
> Pádraig Brady wrote:
>> p.s. Those new --check-order --nocheck-order options confuse me.
>> When they were added I only took a quick look at the implementation
>> rather than the interface (which Bo Borgerson kindly sped up for us).
>> Perhaps something like this would be clearer:
>>
>> --check-order={none,mismatch,unsorted}
>> By default --check-order=mismatch is enabled.
>>
>> I suppose it's too late to change now.
>>
>
> Hi Pádraig,
>
> If I remember correctly the three possibilities are effectively severity
> levels for an 'out-of-order' exception:
>
> --nocheck-order => SILENT (don't actually check)
> [DEFAULT] => WARNING
> --check-order => FATAL
>
> For me "mismatch" and "unsorted" aren't obvious keywords, but I can see
> how an argument to the --check-order option could be clearer than the
> current interface.
>
> Would an _optional_ argument using a scheme like the one you suggested
> above be worth providing? I suspect it might actually add to confusion
> due to the need for continued support for the current scheme as well,
> but it should be possible to allow both:
>
> --nocheck-order => --check-order=none
> [DEFAULT] => --check-order=warning
> --check-order => --check-order=fatal
Ha, I actually tried to infer the meaning from the existing docs
and got more confused. Having a quick look at the code suggests
that {none, warning, fatal} are in fact the 3 modes of operation,
and so --check-order={none,warning,fatal} is best as you suggest.
If we were going to change it I would not support both.
I.E. I would not support the --nocheck-order option.
I guess very few scripts actually use the --nocheck-order option.
I'll think about some doc changes at least to make it clearer.
cheers,
Pádraig.
_______________________________________________
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils
