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

Previous Next

Full log

View this message in rfc822 format

From: Rupert Gallagher <ruga <at> protonmail.com>
To: "eggert <at> cs.ucla.edu" <eggert <at> cs.ucla.edu>
Cc: "76290 <at> debbugs.gnu.org" <76290 <at> debbugs.gnu.org>
Subject: bug#76290: "sort -u" vs "sort -h -u": possible bug
Date: Mon, 17 Feb 2025 23:13:39 +0000

No, I expect the program to do exactly what the manual says. 

   -h, --human-numeric-sort
      compare human readable numbers (e.g., 2K 1G)

Applying -h to the list in my example is expected to be semantically equivalent to not applying -h:

A = { echo -e "a1\na2" | sort }
B = { echo -e "a1\na2" | sort -h }

~ $ echo -e "a1\na2" | sort
a1
a2

~ $ echo -e "a1\na2" | sort -h
a1
a2

Since A = B, the result of -u must be the same on both sets, by logic. The program, however, has a mind of its own.

~ $ echo -e "a1\na2" | sort -u
a1
a2

~ $ echo -e "a1\na2" | sort -h -u
a1




-------- Original Message --------
On 2/16/25 23:22, Paul Eggert <eggert <at> cs.ucla.edu> wrote:

>  On 2025-02-16 03:02, Rupert Gallagher wrote:
>  > The introduction of the unique operator (-u) returns a wrong answer when used with the human sorting operator (-h).
>  
>  The answer is "wrong" only in the sense that sort's documented and
>  implemented behavior is not what you expect.
>  
>  To fix this mismatch between behavior and expectations, don't use -h. It
>  makes sense to not use -h, -h is not intended for uses like that.
>

Previous Next

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