bug#15158: sort complains about incompatible options (that aren't) AND when it shouldn't

[Pádraig Brady]

tag 15158 notabug
close 15158
stop

On 08/21/2013 10:57 PM, Linda Walsh wrote:
> 
> If I tell sort to do a general numeric sort and interpret
> human suffixes, such as
>    sort -gh ...
> 
> sort fails similarly, if I ask it to sort by numeric size and
> respect human suffixes:
>    sort -nh ....
> 
> sort claims:
> sort: options `-dn' are incompatible
> 
> similarly, numeric and general numeric are claimed to be
> incompatible -- how is that?
> 
> Regardless of compatibility or not, sort doesn't
> use even use _1_ of the options that were specified.
> If it always used the latest option specified as other
> utils,  it would still behave in a deterministic manner,
> and give correct output in the majority of cases (if not,
> then state the "question")...
> 
> I don't know which utils have been dumbed down to fail
> on, any, ambiguous input (if it is ambiguous, which I
> argue, it is not -- as there is a prescribed order for
> evaluation), but the emphasis on computer programs
> not being resilient.
> 
> Rigidly making people wrong and refusing to work unless
> they ask you in the exact right language/syntax
> is a step backwards for computer programs.  The idea
> on computers is to make life easier -- and enforcing
> the user to create odd workarounds when the program
> could have gotten it right, feels like user-abuse.

So for these comparison options, it's not obvious what's
going on in the implementation. One might think that if -dn
was specified, that something like "dictionary" was used and
then "numeric" done to break ties. Similary with -gh, one
might think that -h was an adjustment to -g rather than
being a _separate_ comparison method entirely.

The errors are imparting this info to the user.
Given the complexity of the option combinations
for sort(1) in particular, it's important to do so.

The edge case of a default sort invocation using for example -d,
which is then overridden with -n through config, is not usual,
and thus should not proceed, for the reason above.

Now you have a point about non mutually exclusive args,
which I'll respond to in the related bugs you opened.

thanks,
Pádraig.