On Thu, Aug 20, 2009 at 04:10:35AM -0400, Woodchuck wrote:
> Sorry for cowering behind a pseudonymous email address, (...)
> Perhaps this is cowardly in certain nations more closely associated
> with their former or present colonial Masters than my own (...)
Please keep politics off this list and don't be needlessly offensive.
> That said, consider the following:
>
> I have transposed the output to rows for ease of study. For these
> examples, ascii collating order and numeric collating order are by
> coincidence the same.
>
> cat testfile
> 16.88 16.54 15.12 15.00 14.57
>
> sort testfile
> 14.57 15.00 15.12 16.54 16.88 ascii CORRECT
>
> sort -n testfile
> 14.57 15.00 15.12 16.54 16.88 numeric CORRECT
>
> sort -nr testfile
> 16.88 16.54 15.12 15.00 14.57 numeric reversed CORRECT
>
> sort -k1 testfile
> 14.57 15.00 15.12 16.54 16.88 ascii CORRECT
>
> sort -k1n testfile
> 14.57 15.00 15.12 16.54 16.88 numeric CORRECT
>
> sort -k1nr testfile
> 16.88 16.54 15.00 15.12 14.57 incorrect reversed numeric FAILURE
>
> In this example, f(i) >= f(i+1) (reverse numeric sort) is not true.
> 15.00 !>= 15.12 Note that the integer part is sorted correctly.
> Add some more 15.nm to the testfile to see more detail.
>
> Do I misunderstand the man 1 sort entry concerning -k? I suspect
> that attribute "n" is not working for -k.
Works for me on -current amd64:
OpenBSD 4.6-current (GENERIC.MP) #130: Mon Aug 10 18:13:53 MDT 2009
What system are you using?
Joachim
