GNU bug report logs - #76290
"sort -u" vs "sort -h -u": possible bug

Previous Next

Full log

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

From: "Philip Rowlands" <phr+coreutils <at> dimebar.com>
To: "Paul Eggert" <eggert <at> cs.ucla.edu>,
 "Rupert Gallagher" <ruga <at> protonmail.com>
Cc: 76290 <at> debbugs.gnu.org
Subject: Re: bug#76290: "sort -u" vs "sort -h -u": possible bug
Date: Sun, 16 Feb 2025 17:23:18 +0000

On Sun, 16 Feb 2025, at 06:23, Paul Eggert wrote:
> I don't see a bug there, just an infelicity. -h means 'sort' should look 
> for a number, and your data lines don't start with numbers.
>
> Try 'sort --debug -h -u' to see more.

The --debug output here isn't as helpful as it could be; taking a simplified example

$ echo -e 'CVE-222\nCVE-111\nCVE-222' | sort -h -u --debug
sort: text ordering performed using simple byte comparison
sort: note numbers use '.' as a decimal point in this locale
CVE-222
^ no match for key

$ echo $'bbb\naaa' | sort -n -u --debug
sort: text ordering performed using simple byte comparison
sort: note numbers use '.' as a decimal point in this locale
bbb
^ no match for key


Due to the diligent work by maintainers, there are very few genuine bugs in sort, so we can assume --debug users need as much help as possible figuring out where the sort options have gone wrong. How could the "no match for key" output here be clearer? Could --uniq --debug show elided lines with an explanation, especially for entire lines which match nothing?


Cheers,
Phil

Previous Next

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