GNU bug report logs - #9995
problem about sort -u -k

Previous Next

Full log

Message #24 received at 9995 <at> debbugs.gnu.org (full text, mbox):

From: Eric Blake <eblake <at> redhat.com>
To: 9995 <at> debbugs.gnu.org
Subject: Re: bug#9995: problem about sort -u -k
Date: Wed, 09 Nov 2011 20:08:45 -0700

[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   eblake <at> redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.