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

[Matthew Woehlke]

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?

What about:

bash-3.1.17(5)
vim7-52
vim7-101
coreutils-6.3
coreutils-6.4
bash-3.1(6)
vim6
bash-3.1.17-2
bash-3.2(4)
coreutils-5.97

My proposed 'sort -r' would immediately spit out the (roughly*) desired 
result:

bash-3.1.17-2
bash-3.1.17(5)
bash-3.1(6)
bash-3.2(4)
coreutils-5.97
coreutils-6.3
coreutils-6.4
vim6
vim7-52
vim7-101

...with no thought on my part. Can '-k' even handle that?

(* I'm not sure what the desired order of 'a(b)' vs 'a-b' vs 'a.b' is, 
but I don't see that -k addresses that anyway, or if it does -k plus -r 
should handle it.)

> > > > 'a': convert numbers with strtol(,0) (i.e. automatically recognize
> > > > '0x<num>' (hex), '0<num>' (octal).
> > > > 'o': all numbers are octal, i.e. strtol(,8)
> > > > 'x': all numbers are hexadecimal, i.e. strtol(,16)
> > > These shouldn't use strtol; they should work regardless of the size
> > > of the number, just as it already works for decimal numbers.
> > I was actually wondering about that... from the info page it sounded
> > like strtod is actually used,
>
> It is, for -g.  But strtol is not used for ordinary numeric sort.
>
> Ideally, we wouldn't use strtod even for -g.  We would do exact
> comparison, so that, e.g., 1.0000000000000000000000000000000000000000001
> would compare greater than 1.0 (as it already does for -n).  That
> would be some more work, but it shouldn't be _that_ much work.

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

> > (I guess this means you would always convert numbers to [long]
> > doubles?)
>
> 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.)

Anyway, I can certainly keep the non-auto-base cases in string space.

This brings up another question I should probably ask; are digits > 9 
case-sensitive? Does this depend on an option, on the user's locale...?

--
Matthew
If this message is intercepted, the sender will disavow all knowledge of 
its existence.