bug-coreutils
[Top][All Lists]
Advanced

[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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]