bug#6529: --key option problem

[Eric Blake]

On 06/28/2010 08:26 AM, Victor Grishchenko wrote:
> Hi!
> 
> Today I've ran into a problem of the sort ignoring the --key parameter.
> It sorts data according to the alphanumeric order of the full string instead.
> Twiddling here and there (coreutils version, LC_ALL, positions, etc) did not 
> work.
> Any ideas?
> 
> harvest$ zcat data.log.gz | pcregrep '[TR]data' | head -10 | sort --key=17,30 

Thanks for the report.  However, I don't think this is a bug in sort,
but rather a misunderstanding on your part.  Your command says to use as
your primary key the substring consisting of fields 17 through 30, and
as secondary key the entire line.

> 0_01_18_139_840 vtt1_100 vtt2_9#8 Tdata (0,8132)

But your input only has 5 fields, so your primary key is worthless, and
the fallback secondary key explains why you are getting alphanumeric
sorting.

What did you intend to sort by?  If you were typing 17,30 thinking you
were getting bytes instead of fields, thus meaning:

> 0_01_19_377_086 vtt1_100 vtt2_9#8 Tdata (0,8132)
  ................^^^^^^^^^^^^^^..................

then you should use --key=2,3.5 (that is, start with the second field,
and go through the 5th byte of the third field).  You may also want to
use --stable to disable the fallback sort of the entire line.

Also, the next version of coreutils will include 'sort --debug' that
gives you a visual indication of what bytes are actually being compared,
which would have given you a clue that your --key=17,30 was selecting
data outside the range of your input.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature