bug#9334: sort bug

[Bob Proulx]

tags 9334 + notabug
thanks

ROGER GRAYDON CHRISTMAN wrote:
> First: some version information:
> sort (GNU coreutils) 8.4

Thanks!

> 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
this:

  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.
  ...
  `-n'
  `--numeric-sort'
  `--sort=numeric'
       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.

Bob