On 04/16/2010 04:58 AM, Santiago Rodriguez wrote:
> Dear sirs,
> 
> I think I have found a bug in sort coreutils command. When I type
> 
> sort -T /tmp +1 -2 +2rn -3 +0 -1<<EOF
> perra/S perra 2.200000
> perro/PS perra 4.400000
> EOF

Thanks for the report; however, this is not a bug.

The syntax 'sort +1' is obsolete.  You are better off rewriting your
scripts to conform to POSIX:

sort -T /tmp -k2,3 -k3,4rn -k1,2

And in doing so, you've just made it apparent why sort behaved
correctly, but differently than you expected.  Basically, you have
requested that your first sort key be the combination of the second and
third field.  And since 'perra 2.200000' sorts before 'perra 4.400000',
there is no need for sort to fall back on the second and third key
specifications.

You can get the desired results with:

sort -T /tmp -k2,2 -k3,3rn -k1,1

or the obsolete:
sort -T /tmp +1 -1 +2rn -2 +0 -0

Meanwhile, we have a patch brewing (but not in 8.4) that allows sort to
output some debug hints, to actually show which portions of each line
were used in the various comparisons.  I'm hoping we can get that patch
polished soon, because it would have been very helpful in demonstrating
my reply.

> 
> The result is the same. If I make the same executions with sort 5.0 it
> works properly.

Actually, sort 5.0 was buggy in this area.  Sort 8.4 has a number of bug
fixes for bad behavior in sort 5.0.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org