GNU bug report logs - #7961
sort

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Pádraig Brady <P <at> draigBrady.com>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#7961: closed (sort)
Date: Wed, 02 Feb 2011 22:53:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Wed, 02 Feb 2011 22:59:02 +0000
with message-id <4D49E1B6.104 <at> draigBrady.com>
and subject line Re: bug#7961: sort
has caused the GNU bug report #7961,
regarding sort
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
7961: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7961
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Francesco Bettella <francesb <at> decode.is>
To: bug-coreutils <at> gnu.org
Subject: sort
Date: Wed, 2 Feb 2011 12:42:01 +0000

[Message part 3 (text/plain, inline)]

hi,
I may have bumped into an undesired feature/bug of sort, which appears to be 
still present in the version 8.9 of coreutils.

I'm issuing the following sort commands (see attached files):

[prompt1] > sort -k 1.4,1n asd1 > asd1.sorted

[prompt2] > sort -k 2.4,2n asd2 > asd2.sorted

the first one works as I would expect, the second one doesn't.

cheers.

Francesco

[asd1 (text/plain, attachment)]

[asd1.sorted (text/plain, attachment)]

[asd2.sorted (text/plain, attachment)]

[asd2 (text/plain, attachment)]

[Message part 8 (message/rfc822, inline)]

From: Pádraig Brady <P <at> draigBrady.com>
To: Eric Blake <eblake <at> redhat.com>
Cc: 7961-done <at> debbugs.gnu.org, Francesco Bettella <francesb <at> decode.is>
Subject: Re: bug#7961: sort
Date: Wed, 02 Feb 2011 22:59:02 +0000

On 02/02/11 17:44, Eric Blake wrote:
> $ head -3 asd2 | LC_ALL=C sort -k 2.4,2n --debug
> sort: using simple byte comparison
> sort: leading blanks are significant in key 1; consider also specifying `b'
> PRAMEF1>chr1
>           ^ no match for key
> ____________
> PRAMEF4>chr1
>           ^ no match for key
> ____________
> coding_gene>chr
>               ^ no match for key
> 
> But when you add -b (note, b is the one option you have to add to the
> start field, since it affects start and end fields specially; all other
> options can be added to start, end, or both, and affect the entire key):
> 
> $ head -3 asd2 | sort -k 2.4b,2n --debug
> sort: using `en_US.UTF-8' sorting rules
> coding_gene>chr
>                ^ no match for key
> _______________
> PRAMEF1>chr1
>            _


Yep. The 'b' option is one of the main reasons for --debug.
Note, sort --debug will warn until you put it in the right place.

Hmm, I just noticed a bug with --debug, introduced with bdde34f9:

$ printf "A\tchr10\nB\tchr1\n" | ./sort -s --debug -k2.4b,2.3n 2>/dev/null
A>chr10
     __
B>chr1
     _

This should fix it up:

diff --git a/src/sort.c b/src/sort.c
index 06b0d95..365634d 100644
--- a/src/sort.c
+++ b/src/sort.c
@@ -2214,7 +2214,9 @@ debug_key (struct line const *line, struct keyfield const *key)

           char *tighter_lim = beg;

-          if (key->month)
+          if (lim < beg)
+            tighter_lim = lim;
+          else if (key->month)
             getmonth (beg, &tighter_lim);
           else if (key->general_numeric)
             ignore_value (strtold (beg, &tighter_lim));

cheers,
Pádraig.

Previous Next

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