On 12/07/2025 16:53, Paul Eggert wrote:
On 2025-07-12 04:45, Pádraig Brady wrote:
- : a == b ? 0
+ : a == b ? numcompare (sa, sb)
That fails for string pairs like "10" and "1e1".
Hah I thought of that but missed this impacts the --unique case.
I added a test case to ensure
On 2025-07-12 04:45, Pádraig Brady wrote:
- : a == b ? 0
+ : a == b ? numcompare (sa, sb)
That fails for string pairs like "10" and "1e1".
DBL_ABOVE_MIN=$(echo $LDBL_MIN | sed 's/e/1e/')
$ printf '%s\n' $LDBL_ABOVE_MIN $LDBL_MIN | src/sort -g
3.3621031431120935063e-4932
3.36210314311209350631e-4932
$ printf '%s\n' $LDBL_ABOVE_MIN $LDBL_MIN | /usr/bin/sort -g
3.36210314311209350631e-4932
3.3621031431120935063e-4932
cheers,
Pádraig
On 2025-07-11 20:59, Collin Funk wrote:
Maybe a solution would be to compare the strings instead of calling
strold?
Yes, that's been on the 'sort' TODO list for like, forever. It'd also be
faster than what's in there now. A bit tricky, though, given the
vagaries
On 2025-07-11 15:25, Collin Funk wrote:
This test still fails on cfarm110 for me, logs attached.
I guess that's a different issue, due to the problem that Gnulib defines
LDBL_MAX to be a value greater than what one can compute from source code.
I guess a fix on that platform would be to shri
Collin Funk writes:
>> Oh, right. Thanks. I installed the attached further patch to fix that.
>> This is cleaner anyway.
>
> This test still fails on cfarm110 for me, logs attached.
>
> I was looking at it the other day, but was unable to get a working
> version.
>
> I'll see if I have any ideas
.
This test still fails on cfarm110 for me, logs attached.
I was looking at it the other day, but was unable to get a working
version.
I'll see if I have any ideas later.
Collin
sort-float.log.gz
Description: application/gzip
17 00:00:00 2001
From: Paul Eggert
Date: Fri, 11 Jul 2025 14:43:32 -0700
Subject: [PATCH] tests: fix fraction comparison in sort-float
Problem reported by Cosima Neidahl <https://bugs.gnu.org/78985#13>.
* tests/sort/sort-float.sh: At top level, use C locale at first.
(dbl_minima_order): As
Am 10.07.25 um 19:20 schrieb Paul Eggert:
Thanks for reporting that false positive in the test. I installed the
attached patch, which should fix things.
The patch fixes the error with the long fraction part being unparsable,
but it seems like the resulting order for the test input is still wro
Thanks for reporting that false positive in the test. I installed the
attached patch, which should fix things.From 8f9fc8f08c10c3b097211f95c6354a85d41f1101 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Thu, 10 Jul 2025 10:17:29 -0700
Subject: [PATCH] tests: fix integer overflow in sort-float
suite.
These patches are resulting in a failure of the sort-float test from the
coreutils test suite, with the following output:
./tests/sort/sort-float.sh: line 49: test:
225073858507201383090232717332: integer expression expected
--- exp 2025-07-09 14:38:32.521404281 +
+++ out 2025-07
On 20/05/2025 19:24, Paul Eggert wrote:
On 2025-05-20 10:15, Pádraig Brady wrote:
The attached patch addresses the issue here,
and includes a test verified to trigger with ASAN or valgrind available.
Thanks. A nit: the patch doesn't include the change to NEWS.
Good spot.
Fixed and pushed.
M
On 2025-05-20 10:15, Pádraig Brady wrote:
The attached patch addresses the issue here,
and includes a test verified to trigger with ASAN or valgrind available.
Thanks. A nit: the patch doesn't include the change to NEWS.
On 20/05/2025 16:15, Pádraig Brady wrote:
Indeed. I introduced this in coreutils 7.2 (2009).
One can repro on Fedora for e.g. with:
_POSIX2_VERSION=200809 LC_ALL=C valgrind sort +0.18446744073709551615R
poc_input.txt
==984625== Memcheck, a memory error detector
==984625== Using Valgrind-3.24.0
On 20/05/2025 10:31, Med Maatallah wrote:
Dear GNU Coreutils Maintainers,
I am reporting a heap buffer overflow vulnerability (CWE-122) I've
discovered in the GNU Coreutils sort utility. This issue affects the
traditional key specification syntax processing and leads to an
out-of-bounds
ssessed only based on the keys
and rules used to sort the output".
Thanks for the suggestion. Although that's a bit long for "sort --help",
I take the point that equality comparison could be mentioned and
installed the attached to try to make thing
On 19.02.25 18:14, Bernhard Voelker wrote:
On 2/18/25 7:45 PM, Rupert Gallagher via GNU coreutils Bug Reports wrote:
By comparison, human (-h) and numeric (-n) sort cause data loss:
not really. That's the difference between
a)
"I have a list containing numbers; I merely care abo
On 2/18/25 7:45 PM, Rupert Gallagher via GNU coreutils Bug Reports wrote:
By comparison, human (-h) and numeric (-n) sort cause data loss:
not really. That's the difference between
a)
"I have a list containing numbers; I merely care about numbers and want to get a
unique, sort
Dictionary sort corresponds to the intended behaviour.
> echo -e "abc\n123\n456\nCVE-2011-234\nAbc\ndef\nCVE-2024-123" | sort --debug
> -dfu
123
___
456
___
abc
___
CVE-2011-234
CVE-2024-123
def
___
By comparison, human (-h) and numeric (-n) sort
According to gnu sort -h -u and what you claim to be common practice, a list of
possibly redoundant strings, some beginning with a number, is reduced to an
ordered set of the numbered strings only.
Since I expect the resulting ordered set to include the original elements, I
will then stop
On 2025-02-17 15:13, Rupert Gallagher via GNU coreutils Bug Reports wrote:
I expect the program to do exactly what the manual says.
Here's what the manual says about -u in
<https://www.gnu.org/software/coreutils/manual/html_node/sort-invocation.html#index-uniquifying-output>:
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
On 2025-02-17 15:13, Rupert Gallagher wrote:
~ $ 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.
By that logic, since the output of these two commands:
echo -e 'a1\na2&
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 mismat
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
My concern is best described as follows.
~ $ echo -e
"CVE-2018-13787\nCVE-2019-16649\nCVE-2019-16650\nCVE-2020-15046\nCVE-2018-13787"
| sort -h
CVE-2018-13787
CVE-2018-13787
CVE-2019-16649
CVE-2019-16650
CVE-2020-15046
~ $ echo -e
"CVE-2018-13787\nCVE-2019-16649\nCVE-2019-
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.
>echo -e
>"CVE-2018-13787\nCVE-2019-16649\nCVE-2019-16650\nCVE-2020-15046\nCVE-2018-13787"
CVE-2018-13787 <---
CVE-2019-16649
CVE-2019-16650
CVE-2020-15046CVE-2018-13787 <---
>echo -e
>"CVE-2018-13787\nCVE-2019-16649\nCVE-2019-16650\nCVE-2020-15046\nCVE-20
| egrep -o
> >
> > '(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-
> > 9][0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)'
> > 64.227.127.122
> > 172.169.5.249
> > 172.169.6.164
>
> Addi
ned in the online documentation,
so I won't repeat here. See the --unique description at:
https://www.gnu.org/software/coreutils/sort
cheers,
Pádraig
0-9]?)\.(25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)'
64.227.127.122
172.169.5.249
172.169.6.164
Adding the --debug option shows the issue.
I.e. the '.' being considered as part of a number:
$ sort --debug -rbn -s ips
sort: text ordering performed using ‘en_IE.UTF-8’ sorting rules
s
3.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
142.93.95.82
35.94.106.188
115.231.78.8
34.223.41.242
35.84.141.160
159.65.29.253
115.231.78.8
The expected return of sort (sort -urbn) is:
178.128.
>>>>> "PB" == Pádraig Brady writes:
PB> All good suggestions. I'll at least add an example along the lines of:
PB> awk '{print $NF, $0}' | sort -k1,1 | cut -f2- -d' '
OK, also say what it's doing. Not everybody knows awk.
Also joi
On 23/04/2024 11:14, Dan Jacobson wrote:
In (info "(coreutils) sort invocation") be sure to add an example of a
way or workaround for counting fields from the end of the line. E.g., we
want to sort on the last field, but don't know for sure how many fields
a line might contain
In (info "(coreutils) sort invocation") be sure to add an example of a
way or workaround for counting fields from the end of the line. E.g., we
want to sort on the last field, but don't know for sure how many fields
a line might contain. E.g., sort by surname, when lines consist o
On 06/04/2024 23:22, Paul Eggert wrote:
On 2024-04-06 03:09, Pádraig Brady wrote:
I'll apply this.
Heh, I beat you to it by looking for similar errors elsewhere and
applying the attached patches to fix the issues I found. None of them
look like serious bugs.
Cool. I thought the s
On 2024-04-06 03:09, Pádraig Brady wrote:
I'll apply this.
Heh, I beat you to it by looking for similar errors elsewhere and
applying the attached patches to fix the issues I found. None of them
look like serious bugs.
BTW we should improve sort buffer handling in general
Oh yes
On 06/04/2024 03:52, Takashi Kusumi wrote:
Hi,
I have found a performance issue with the sort command when used on
pseudo files with zero size. For instance, sorting `/proc/kallsyms`, as
demonstrated below, takes significantly longer than executing with
`cat`, generating numerous temporary
Hi,
I have found a performance issue with the sort command when used on
pseudo files with zero size. For instance, sorting `/proc/kallsyms`, as
demonstrated below, takes significantly longer than executing with
`cat`, generating numerous temporary files. I confirmed this issue on
v8.32 as well
On 3/19/24 08:33, Rafal Maszkowski wrote:
he --debug option advised in
README does not say anything helpful:
(echo a; echo b) | sort --debug -nu
sort: text ordering performed using simple byte comparison
a
^ no match for key
That diagnostic message is helpful. It's telling you that there
Sort with -n and -u options works correctly for numbers:
(echo 10; echo 11) | sort -nu
10
11
but looses data when used with non-numbers:
(echo a; echo b) | sort -nu
a
(echo 1.0; echo 1.1) | sort -nu
1.0
I have tested this on versions 8.32 and 9.2 default for Debian 11 and
12, and additionally
tag 67690 notabug
close 67690
stop
On 07/12/2023 14:36, Oleg Moiseichuk via GNU coreutils Bug Reports wrote:
Hello!
I've got a list of IP addresses, each of them is prepended by its frequency
counter (please find attached in the file list-1.txt). I need to sort them from
most freque
Hello!
I've got a list of IP addresses, each of them is prepended by its frequency
counter (please find attached in the file list-1.txt). I need to sort them from
most frequent to least. I tried using this command:
sort -t '.' -n -k 1.1,1.8r -k 1.9 -k 2,2 -k 3,3 -k 4,4 list-1.t
On 9/28/23 04:22, Pádraig Brady wrote:
-n, --numeric-sort compare according to string numerical value.
leading blanks, negative sign, decimal
point,
and thousands separators are supported.
Although a valiant
On 28/09/2023 11:11, Jorge Stolfi wrote:
The full documentation of sort explains that numeric sorting (as in
"sort -n") accepts a leading "-" sign, decimal points, thousands
separators, etc, but does not accept an explicit "+" sign. Values with
explicit "+&quo
The full documentation of sort explains that numeric sorting (as in
"sort -n") accepts a leading "-" sign, decimal points, thousands
separators, etc, but does not accept an explicit "+" sign. Values with
explicit "+" are treated as numeric 0 and ties
Pádraig Brady wrote:
> The fact that ',' isn't used as the decimal point is surprising,
> and is what's causing the test to fail.
Ah, I see. Yes, for some tests one only needs a fr_FR.UTF-8 that supports
UTF-8 in LC_CTYPE, whereas for other tests it also needs to support the
LC_NUMERIC category co
On 15/08/2023 14:14, Bruno Haible wrote:
Hi,
Doing "make check" of current coreutils on Alpine Linux 3.18, I see a
test failure that I didn't see with the coreutils-9.3 release:
FAIL: tests/sort/sort-debug-keys
I'm attaching the relevant part of tests/test-suite.log.
Hi,
Doing "make check" of current coreutils on Alpine Linux 3.18, I see a
test failure that I didn't see with the coreutils-9.3 release:
FAIL: tests/sort/sort-debug-keys
I'm attaching the relevant part of tests/te
tag 61696 notabug
close 61696
stop
On 22/02/2023 01:26, Dan Jacobson wrote:
At (info "(coreutils) sort invocation") it says
For example, ‘sort -n -u’ inspects only the value of the initial
numeric string when checking for uniqueness, whereas ‘sort -n | uniq’
inspects the e
At (info "(coreutils) sort invocation") it says
For example, ‘sort -n -u’ inspects only the value of the initial
numeric string when checking for uniqueness, whereas ‘sort -n | uniq’
inspects the entire line. *Note uniq invocation::.
OK, but you still need to add a warning about
tag 60544 notabug
close 60544
stop
On 04/01/2023 04:38, DE CARNE DE CARNAVALET, Xavier [COMP] wrote:
sort seems to do extra computations on long line with invalid UTF8 characters
and could hang for days on just two lines.
Here is the minimal example I could make to reproduce the bug:
$ perl
sort seems to do extra computations on long line with invalid UTF8 characters
and could hang for days on just two lines.
Here is the minimal example I could make to reproduce the bug:
$ perl -e 'print "\xcd\xe5\xe0"; print "\n"' > file1
$ perl -e 'print &q
uld be preferred as the latest version.
However, for "sort" or "ls", one may have "foo" and "foo-0" at
the same time, and they need to be sorted. For instance, 0 could
be regarded as an epsilon. So the sorting in my example would be
correct.
--
Vince
On 12/10/2022 22:07, Vincent Lefevre wrote:
A regression in version sort (used as the natural sort for "ls")
has been introduced from coreutils 8.32 to 9.1:
With coreutils 8.32 (Debian 11):
$ printf "%s\n" a a0 a1 a.b a0.b a1.b | sort -V
a
a.b
a0
a0.b
a1
a1.b
With c
A regression in version sort (used as the natural sort for "ls")
has been introduced from coreutils 8.32 to 9.1:
With coreutils 8.32 (Debian 11):
$ printf "%s\n" a a0 a1 a.b a0.b a1.b | sort -V
a
a.b
a0
a0.b
a1
a1.b
With coreutils 9.1 (Debian/unstable):
$ printf "%s
On 28/09/2022 22:13, DrSlony wrote:
Hey
printf '%s\n' "key;foo" "key0;bar0" | sort -Vu -t ';' --key=1,1
sort 8.32 outputs:
key;bar
key0;foo
sort 9.1 outputs:
key;foo
"key0;foo" is missing.
You're using version sort
Hey
printf '%s\n' "key;foo" "key0;bar0" | sort -Vu -t ';' --key=1,1
sort 8.32 outputs:
key;bar
key0;foo
sort 9.1 outputs:
key;foo
"key0;foo" is missing.
Regards
Morgan
I installed the attached spelling fix to a comment in my previous patch.From 8c1a447a3790ec74ef919c60d46673e7be061c72 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 25 May 2022 11:49:13 -0700
Subject: [PATCH] maint: spelling fix
---
src/sort.c | 2 +-
1 file changed, 1 insertion(+), 1 de
lesce duplicate code
and explain why it's needed and (2) tweak performance a tiny bit.
From 15627794459933d293547c2bf7d77ab196ae73a3 Mon Sep 17 00:00:00 2001
From: Paul Eggert
Date: Wed, 25 May 2022 11:19:08 -0700
Subject: [PATCH 1/2] sort: refactor tricky diff reversal
* src/sort.c
On 25/05/2022 03:00, Larry Ploetz wrote:
I think I've found a bug in sort (git branch master). The --reverse flag
seems to be ignored when --keys are supplied.
larryp-MBP:bin larry$ ./sort --version
sort (GNU coreutils) 9.1.17-a351f
Copyright (C) 2022 Free Software Found
I think I've found a bug in sort (git branch master). The --reverse flag
seems to be ignored when --keys are supplied.
larryp-MBP:bin larry$ ./sort --version
sort (GNU coreutils) 9.1.17-a351f
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version
On 5/10/22 12:08, coreut...@tlinx.org wrote:
Unless there is some magic about -n1238095,
The test is random and there's no magic, just luck. The larger the
random test, the more likely you'll run into the unlucky situation where
the unpatched 'sort' infloops.
On 2022/05/01 10:16, Giulio Genovese wrote:
As explained here
<https://unix.stackexchange.com/questions/700863/gnu-linux-sort-g-can-hang-indefinitely-when-run-on-standard-input-on-ubuntu>,
when running "sort -g" from standard input, if NaNs are involved, this can
cause &
Thanks for reporting that. Fixed as described here:
https://bugs.gnu.org/55212
: 'time' needs to be at the end of the pipeline:
$ yes nan | head -n128095 | bash -c 'time src/sort -g' >/dev/null
real0m0.552s
user0m0.551s
sys 0m0.001s
$ yes nan | head -n128095 | bash -c 'time sort -g' >/dev/null
real0m0.392s
user0m0.382
https://unix.stackexchange.com/a/700967/2972
dd if=/dev/urandom count=80 bs=1 | od -An -t f4 -w4 | sponge | sort -g
goes into infinite loop.
It is caused by 'nan' showing up at a position that apparently is bad.
This works (100x bigger than the example above but removes
On 02/05/2022 07:03, Paul Eggert wrote:
Thanks for the bug report. This bug is entertaining, as it comes from
GCC now being so smart that it optimizes away a memset that cleared
padding bits. We added the memset in coreutils 8.14 (2011) to try to fix
the sort -g infinite loop bug (introduced in
Thanks for the bug report. This bug is entertaining, as it comes from
GCC now being so smart that it optimizes away a memset that cleared
padding bits. We added the memset in coreutils 8.14 (2011) to try to fix
the sort -g infinite loop bug (introduced in 1999), but the memset isn't
guara
As explained here
<https://unix.stackexchange.com/questions/700863/gnu-linux-sort-g-can-hang-indefinitely-when-run-on-standard-input-on-ubuntu>,
when running "sort -g" from standard input, if NaNs are involved, this can
cause "sort -g" to hang indefinitely while consu
On 4/19/21 06:15, 積丹尼 Dan Jacobson wrote:
Let's face it, sort, no matter what --option, or LC_... value,
just can't achieve this order:
3－1號邊
3號之1
3號之2
30
Plain 'sort -n' works for me, in my en_US.utf8 locale. :-)
I do take your point, though, that GNU 'sort'
As Michael mentioned, sort -V mishandled NUL. I fixed this by adding a
Gnulib function filenvercmp that treats NUL as just another character.
* As Michael also mentioned, filevercmp fell back on strcmp if version
sort found no difference, which meant sort's --stable flag was
ineffective. I fi
h the documentation. I could
be talked into the other way; it shouldn't matter much either way.
* The code did the preliminary test (without suffixes) using strcmp, the
documentation said it should use version comparison. Here I went with
the documentation.
* As Michael mentioned, sort -V
Thank you for working on this. Your points are well taken. One tiny comment:
+ if (basic_numeric_field)
+{
+ if (thousands_sep_ignored)
This might be better combined as "if (basic_numeric_field &&
thousands_sep_ignored)", so that it's more similar to the previous "if".
On 11/10/2021 02:54, Pádraig Brady wrote:
On 11/10/2021 00:34, Paul Eggert wrote:
The warnings look good, except that this one:
$ printf '1.0\n0.9\n' | sort -s -k1,1g --debug
sort: numbers use ‘.’ as a decimal point in this locale
0.9
___
1.0
___
seem
On 11/10/2021 00:34, Paul Eggert wrote:
The warnings look good, except that this one:
$ printf '1.0\n0.9\n' | sort -s -k1,1g --debug
sort: numbers use ‘.’ as a decimal point in this locale
0.9
___
1.0
___
seems overkill if we're in the C locale.
On 10/10/2021 22:20, Bernhard Voelker wrote:
On 10/10/21 19:57, Pádraig Brady wrote:
sort: numbers use ‘.’ as a decimal point in this locale
What about adding the hint to that message that this an "ambiguity warning"?
sort: ambiguity warning: numbers use ‘.’ as a decima
The warnings look good, except that this one:
$ printf '1.0\n0.9\n' | sort -s -k1,1g --debug
sort: numbers use ‘.’ as a decimal point in this locale
0.9
___
1.0
___
seems overkill if we're in the C locale.
Also, shouldn't similar diagnostics be ge
On 10/10/21 2:20 PM, Bernhard Voelker wrote:
What about adding the hint to that message that this an "ambiguity warning"?
I don't think it's ambiguous (merely confusing :-).
On 10/10/21 19:57, Pádraig Brady wrote:
> sort: numbers use ‘.’ as a decimal point in this locale
What about adding the hint to that message that this an "ambiguity warning"?
sort: ambiguity warning: numbers use ‘.’ as a decimal point in this locale
(Likewise for the ot
On 09/10/2021 23:29, Paul Eggert wrote:
On 10/9/21 5:00 AM, Pádraig Brady wrote:
On 09/10/2021 04:48, Paul Eggert wrote:
'sort' could determine the group sizes from the locale, and
reject digit strings that are formatted improperly according to the
group-size rules. (Not that I pla
On 10/9/21 5:00 AM, Pádraig Brady wrote:
On 09/10/2021 04:48, Paul Eggert wrote:
'sort' could determine the group sizes from the locale, and
reject digit strings that are formatted improperly according to the
group-size rules. (Not that I plan to write the code to do that)
Y
On 09/10/2021 04:48, Paul Eggert wrote:
On 10/8/21 7:32 PM, Pádraig Brady wrote:
it's not a thousands separator, rather a grouping
character,
and groups can be in 2, 3, 4, and even 5.
Sure, but 'sort' could determine the group sizes from the locale, and
reject digit strings tha
On 10/8/21 7:32 PM, Pádraig Brady wrote:
it's not a thousands separator, rather a grouping
character,
and groups can be in 2, 3, 4, and even 5.
Sure, but 'sort' could determine the group sizes from the locale, and
reject digit strings that are formatted improperly accordin
and groups can be in 2, 3, 4, and even 5. So I don't think we should
change the logic here.
This bug report suggests that we should alter the code so that 'sort -n'
acts more like common practice, and requires thousands separators to be
in the right places in order to treat nea
's obviously not one (as it's not followed by 3 decimal
digits). I don't think POSIX requires this behavior; it's not clear to
me that POSIX even allows it.
This bug report suggests that we should alter the code so that 'sort -n'
acts more like common practice, and
On 04/10/2021 21:01, Paul Eggert wrote:
On 10/4/21 08:58, Pádraig Brady wrote:
The --debug option points out the issue:
$ printf '%s\n' 1,a 0,9 | sort --debug -nk1 -t ,
sort: key 1 is numeric and spans multiple fields
1,a
_
___
0,9
___
___
As Junch
Thank you, Paul and Padraig!
May I ask when it fails to sort numerically why 1,a comes before 0,9? I could
not come up with an ordering that 1,a is smaller.
Best,
Jason
> On Oct 4, 2021, at 4:01 PM, Paul Eggert wrote:
>
> On 10/4/21 08:58, Pádraig Brady wrote:
>> The
On 10/4/21 08:58, Pádraig Brady wrote:
The --debug option points out the issue:
$ printf '%s\n' 1,a 0,9 | sort --debug -nk1 -t ,
sort: key 1 is numeric and spans multiple fields
1,a
_
___
0,9
___
___
As Juncheng points out, it is a bit odd that -n and -g dis
tag 51011 notabug
close 51011
stop
On 04/10/2021 15:36, Juncheng Yang wrote:
Hi coreutils developers,
I have encountered a bug in GNU sort in which sort produces incorrect
results when numerical sort with delimiters. For example,
sort -nk1 -t , file
cannot sort the a file with the
On Mon, 4 Oct 2021 10:36:52 -0400, Juncheng Yang
wrote:
> Hi coreutils developers,
> I have encountered a bug in GNU sort in which sort produces incorrect
> results when numerical sort with delimiters. For example, sort -nk1 -t ,
> file cannot sort the a file with the following
Hi coreutils developers,
I have encountered a bug in GNU sort in which sort produces incorrect
results when numerical sort with delimiters. For example,
sort -nk1 -t , file
cannot sort the a file with the following lines (sort by the first column
numerically)
1,a
0,9
I have tried
On 7/2/21 4:19 PM, Pádraig Brady wrote:
we might be able to improve things.
For example, using strxfrm() + strcmp() to minimize processing.
I tried that long ago, and it was waaayyy slower than strcoll in the
typical case. glibc strxfrm is not at all optimized.
Which is fine, since strxfrm i
On 02/07/2021 20:32, Jon Klaas wrote:
Hello,
I encountered a file that was taking hours to sort that was expected
to take negligible time. This seems to be due to the locale
LANG=en_US.UTF-8. I've worked around the problem by using LC_ALL=C, but
thought I would report this, as I didn&#x
Hello,
I encountered a file that was taking hours to sort that was expected
to take negligible time. This seems to be due to the locale
LANG=en_US.UTF-8. I've worked around the problem by using LC_ALL=C, but
thought I would report this, as I didn't see a relevant bug report.
This w
On Monday, June 28, 2021 6:52:14 PM CEST Michael Debertol wrote:
> I was trying to say that the regex is not followed in two cases:
>
> - when there are two dots followed by [A-Za-z~], the second dot should
> be matched, but it is not.
>
> An example is "foo..a": In this case ".a" should be match
Am 28.06.21 um 18:41 schrieb Kamil Dudka:
On Sunday, June 27, 2021 12:04:53 AM CEST Michael wrote:
Hi,
I found some unexpected results with sort -V. I hope this is the correct
place to send a bug report to [1].
They are caused by a bug in filevercmp inside gnulib, specifically in the
function
On Sunday, June 27, 2021 12:04:53 AM CEST Michael wrote:
> Hi,
> I found some unexpected results with sort -V. I hope this is the correct
> place to send a bug report to [1].
> They are caused by a bug in filevercmp inside gnulib, specifically in the
> function match_suffix.
>
Hi,
I found some unexpected results with sort -V. I hope this is the correct
place to send a bug report to [1].
They are caused by a bug in filevercmp inside gnulib, specifically in the
function match_suffix.
I assume it should, as documented, match a file ending as defined by this
regex: /(\.[A
John regarding the sort issue which was happening. . I wrote to Linux org.
Here is the solution they gave.
To get the effect you want, set *LC_ALL="C"* in your environment. See:
This is what we have.
>set|grep LC
*LC_ALL=en_US*
MAILCHECK=600
I can set the environment , but need to
1 - 100 of 2311 matches
Mail list logo
