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