[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#5958: Sort-8.4 bug

From: Eric Blake
Subject: bug#5958: Sort-8.4 bug
Date: Fri, 16 Apr 2010 08:12:20 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20100330 Fedora/3.0.4-1.fc12 Lightning/1.0b1 Thunderbird/3.0.4

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

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

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   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]