GNU Core Utilities - Bugs: bug #20883, sort -u -n drops more lines than...
You are not allowed to post comments on this tracker with your current authentication level.
bug #20883: sort -u -n drops more lines than expected
Submitter: | None | ||
Submitted: | Fri 24 Aug 2007 05:52:13 AM UTC | ||
Category: | None | Severity: | 3 - Normal |
Item Group: | None | Status: | None |
Privacy: | Public | Assigned to: | rwp |
Open/Closed: | Closed |
Fri 24 Aug 2007 07:32:13 AM UTC, comment #1: |
Bob Proulx <rwp> |
Fri 24 Aug 2007 05:52:13 AM UTC, original submission:
Given the following example input:
|
Anonymous |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Follow 2 latest changes.
Date | Changed by | Updated Field | Previous Value | => | Replaced by |
---|---|---|---|---|---|
2007-08-24 | rwp | Assigned to | None | rwp | |
Open/Closed | Open | Closed |
Powered by Savane 3.13-f8d8.
Corresponding source code
Thanks for the report but this is not a bug but simply a misunderstanding of what sort is using as a sort key. Note that since this is an anonymous bug posting I cannot respond other than by posting a response to the bug.
By default sort will consider the entire line as the sort key. When using the -n numeric sort flag this is still true. The reason sort -u is collapsing lines is because the sort key cause sort to believe the lines are equivalent. Unless -k is specified to restrict the sort key the default key is the entire line.
The way to sort that input numerically on two different fields is to use the -k option to select both fields. Try this:
sort -k1,1n -k2,2n -u
1 1
1 2
1 3
2 1
3 1
That will provide the result that you are looking to achieve.