[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#9995: problem about sort -u -k
From: |
Eric Blake |
Subject: |
bug#9995: problem about sort -u -k |
Date: |
Wed, 09 Nov 2011 20:08:45 -0700 |
User-agent: |
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110928 Fedora/3.1.15-1.fc14 Lightning/1.0b3pre Mnenhy/0.8.4 Thunderbird/3.1.15 |
[top-posting on technical lists is generally frowned on]
[re-adding the list - it's always wiser to keep the list in the loop]
On 11/09/2011 07:25 PM, 夏凯 wrote:
actually, i just want the result of sort -sk3 a|uniq, we can't just
use -u to instead of uniq?
Nope, and I already explained why and gave a sample file to demonstrate
it. These two are equivalent:
sort -k3 a | uniq
sort -u -k3 -k1 a
but there is no way to get both stable sorting that leaves fields 1 and
2 unsorted and in the original order, as well as stripping adjacent
duplicate lines, without also involving a separate uniq process. That
is, there is no one-process counterpart to:
sort -s -k3 a | uniq
The reason is that the only way to match uniq behavior is to have the
sort key cover the entire line, but the moment you add -k1 to cover the
entire line, your sort is no longer stable on your original sort of just
-k3.
Also, you may want to consider whether -k3 is what you really meant, or
if you want to use -k3,3 (that is, whether sorting by the entire line
except for the first two fields, or sorting by just the third field
while ignoring any fourth or later field). Note that I intentionally
used -k1 as shorthand for the entire line.
--
Eric Blake address@hidden +1-801-349-2682
Libvirt virtualization library http://libvirt.org