GNU bug report logs - #10985
sort -k behavior possible problem: field span across the boundaries

Previous Next

Package: coreutils;

Reported by: Oleg Moskalenko <oleg.moskalenko <at> citrix.com>

Date: Fri, 9 Mar 2012 19:58:01 UTC

Severity: normal

Tags: notabug

Done: Eric Blake <eblake <at> redhat.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Oleg Moskalenko <oleg.moskalenko <at> citrix.com>
To: 10985 <at> debbugs.gnu.org
Subject: bug#10985: sort -k behavior possible problem: field span across the boundaries
Date: Fri, 9 Mar 2012 11:46:45 -0800
[Message part 1 (text/plain, inline)]
Hi

While testing different GNU coreutils sort versions on different platforms (Linux and FreeBSD) I found that some behavior is probably not what a utility user expects.

Let's, say, we have to sort (numerically stable) just two lines:

$ sort -t "|" -ns -k2.3,2.7 <<!
1|234
1|2|34
!

The GNU sort output is:

1|234
1|2|34


The correct output (from my point of view) must be:

1|2|34
1|234

My reasoning is that applying the key specs "-k2.3,2.7" to string "1|234" we obtain the key "4", and applying the same key to the string "1|2|34" we must obtain "" (empty string), because the second field is just "2" and symbols from 3rd to 7th position give us an empty string. And the empty string is smaller than a number, numerically, according to the "info sort".

On the other hand, the GNU sort (I suppose) just takes an offset from the field start, without taking into account the real field length. It yields the key "34", and this is larger, numerically, than "4".

I do not know whether this is an intended behavior or a bug, but this is definitely non-intuitive and not what a reasonable user would expect.

Thanks a lot !
Oleg Moskalenko

[Message part 2 (text/html, inline)]

This bug report was last modified 13 years and 71 days ago.

Previous Next


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