Re: RFC: add'l 'sort -n' options

[Paul Eggert]

Matthew Woehlke <address@hidden> writes:

> Paul Eggert wrote:
>> Matthew Woehlke writes:
>>> Paul Eggert wrote:
>>>> Matthew Woehlke writes:
>>>>> '-N _options_, --numeric-sort=_options_'
>>>> The other sort options can be attached to -k; how would this work
>>>> here?
>>> Sorry, I'm not sure I understand what you mean by this comment. What
>>> would be attached to -k, and how?
>> For example, "sort -k2,2n -k3,3g" says sort numerically in column 2,
>> breaking ties with a general numeric sort in column 3.
>
> Ok, but how would I sort these?
>
> 2006-11-06 13:20:15
> 2006-11-05 12:18:04
> 2006-11-06 13:20:37
> 2005-04-01 01:01:01
>
> ...see where the number of args to '-k' quickly gets out of hand?

Sure, but my point was not that the new options can be implemented
with -k.  It is that there needs to be some way to attach the new
options to particular keys.  That is, one would like to sort with
your new -Nr option just on these two keys, and then sort with
some other options on other keys.

> (Although, it really so trivial to determine which of "1000.0"
> and "1.0e3" is larger? :-))

It is not completely trivial to do it in general, but it is doable.
The harder case is when you are comparing multiples of powers of 2.

>> No, you compare the strings directly, without converting to integer
>> or
>> double.  That is how the existing code works for -n.
>
> I'm not sure that would work. Which of "1564863215536" or
> "0x16C591DB7B0" is larger? :-) (Only a problem with base=auto, of
> course, but it illustrates why I don't see an easy way to do the
> comparison purely in string-space.)

Yes, that illustrates the harder case.

> This brings up another question I should probably ask; are digits > 9
> case-sensitive?

I don't see why they would be.

I suppose you could add an option to let the user specify the spelling
of the digits, but perhaps this is overkill.