[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9334: sort bug
bug#9334: sort bug
Sun, 21 Aug 2011 19:55:57 -0600
tags 9334 + notabug
ROGER GRAYDON CHRISTMAN wrote:
> First: some version information:
> sort (GNU coreutils) 8.4
> I run a series of pipes, and after piping into 'sort -n', I see this:
> 1 12
> 1 4
> 5 16
> 9 20
> The first column sorted correctly, numerically, but the second did not.
> I do not have sufficient data to determine whether the second column
> is sorted lexicographically, or simply ignored.
Thanks for the report but you are not seeing a bug in sort but in the
use of it. You have insufficiently qualified the sort criteria. Try
sort -n -k1,1 -k2,2
Or my preference:
sort -k1,1n -k2,2n
The reasoning is as found in the sort documentation:
A pair of lines is compared as follows: `sort' compares each pair of
fields, in the order specified on the command line, according to the
associated ordering options, until a difference is found or no fields
are left. If no key fields are specified, `sort' uses a default key of
the entire line. Finally, as a last resort when all keys compare
equal, `sort' compares entire lines as if no ordering options other
than `--reverse' (`-r') were specified. The `--stable' (`-s') option
disables this "last-resort comparison" so that lines in which all
fields compare equal are left in their original relative order. The
`--unique' (`-u') option also disables the last-resort comparison.
Sort numerically. The number begins each line and consists of
optional blanks, an optional `-' sign, and zero or more digits
possibly separated by thousands separators, optionally followed by
a decimal-point character and zero or more digits. An empty
number is treated as `0'. ...
Since no fields are specified sort is using a default key of the
entire line. Since you care about sorting on fields you should
include sort field options.