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
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".
appropriate to warn
when we're ignoring multi-byte grouping chars in the locale.
The new warnings in this update are:
$ LC_ALL=fr_FR.utf8 sort -n --debug /dev/null
sort: the multi-byte number group separator in this locale is not supported
$ sort --debug -t- -k1n /dev/null
sort: k
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.
Also, shouldn't simila
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 decimal point in thi
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 generated if the field separat
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 other cases, of cours
Pádraig
>From 06410ad77fcd80010859586cc068d8931bcf74e6 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?P=C3=A1draig=20Brady?=
Date: Sun, 10 Oct 2021 18:35:59 +0100
Subject: [PATCH] sort: --debug: add warnings about radix and grouping chars
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Cont
On 16/02/19 23:28, 積丹尼 Dan Jacobson wrote:
>> "PB" == Pádraig Brady writes:
> PB> Fair point. I'm thinking of this extra qualification:
>
> PB> sort: text ordering performed using ‘en_IE.UTF-8’ sorting rules
> Maybe say 'LC_CTYPE=en_IE.UTF-8'
>
> "PB" == Pádraig Brady writes:
PB> Fair point. I'm thinking of this extra qualification:
PB> sort: text ordering performed using ‘en_IE.UTF-8’ sorting rules
Maybe say 'LC_CTYPE=en_IE.UTF-8'
sorting rules
PB> sort: text ordering performed usi
On 15/02/19 06:21, 積丹尼 Dan Jacobson wrote:
> Can you please have assure the user in that message it makes
> that it has indeed seen his -n/--numeric-sort.
>
> $ sort --debug
> sort: using simple byte comparison
> $ sort --debug --numeric-sort
> sort: using s
Can you please have assure the user in that message it makes
that it has indeed seen his -n/--numeric-sort.
$ sort --debug
sort: using simple byte comparison
$ sort --debug --numeric-sort
sort: using simple byte comparison
unchanged. User gets nervous.
sort (GNU coreutils
close 23677
stop
(triaging old bugs)
On 2016-06-02 4:09 p.m., Eric Blake wrote:
On 06/02/2016 03:28 PM, Karl Berry wrote:
They are not ignored, just considered only secondary, if the first
order characters didn't provide an ordering.
Ok. One would have no clue of that, either, from
tags 7214 wontfix
close 7214
stop
(triaging old bugs)
On 14/10/10 10:48 AM, Paul Eggert wrote:
On 10/14/10 05:44, Jim Meyering wrote:
*val = SIZE_MAX;
+ if (debug) /* Note --debug must come before keys to diagnose this. */
+error (0, 0, _("%" PRIuMAX " is too large, usin
On 29/10/17 11:40, 積丹尼 Dan Jacobson wrote:
> < P.S., Yes indeed I had LC_COLLATE=C so maybe --debug should mention
> < where in the environment it made it choices from too.
>
> Ah, like you said
>
> $ LC_ALL=en_CA.UTF-8 sort --debug < /dev/null
> sort: usi
< P.S., Yes indeed I had LC_COLLATE=C so maybe --debug should mention
< where in the environment it made it choices from too.
Ah, like you said
$ LC_ALL=en_CA.UTF-8 sort --debug < /dev/null
sort: using ‘en_CA.UTF-8’ sorting rules
$ LC_ALL=C sort --debug < /dev/null
sort:
Your answer is absolutely pure gold for a new page linked from
‘--debug’
Highlight the portion of each line used for sorting. Also issue
warnings about questionable usage to stderr.
in the Info manual! Please don't let it go to waste sitting in the bug
tracker. Perhaps call it Debuggin
separator.
It is used to sort lines for which the specified keys are equal.
It can be disabled with "-s/--stable" option.
Consider the following:
Case 1: The first key is equal ("A" in both lines).
Sort then uses the last resort sorting and compares the entire
lines, making &
$ sort -k 2n -k 3n --debug file.txt
sort: using simple byte comparison
sort: key 1 is numeric and spans multiple fields
sort: key 2 is numeric and spans multiple fields
41 011 92.3 亞太
___
41 011 97.1 大漢
___
OK but they look like they only span one fie
On 06/02/2016 03:28 PM, Karl Berry wrote:
> They are not ignored, just considered only secondary, if the first
> order characters didn't provide an ordering.
>
> Ok. One would have no clue of that, either, from the --debug output.
>
> sort obviously knows the exact rules defined by the l
They are not ignored, just considered only secondary, if the first
order characters didn't provide an ordering.
Ok. One would have no clue of that, either, from the --debug output.
sort obviously knows the exact rules defined by the locale, or it
couldn't do its job. How about a way to
Karl Berry writes:
> Due to the locale rules, the punctuation characters are being ignored
> (presumably),
They are not ignored, just considered only secondary, if the first order
characters didn't provide an ordering.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58
Consider this two-line input file:
M !z
M /a
(! = ASCII 33; / = ASCII 47.)
Locale-dependent sort with debug:
LC_ALL=en_US.UTF-8 sort --debug -k2 /tmp/foo
Output:
sort: using âen_US.UTF-8â sorting rules
..
M /a
___
M !z
___
Due to the locale rules, the punctuation characters are
Pádraig Brady wrote:
> On 17/06/11 19:34, Jim Meyering wrote:
>> Stefano Lattarini wrote:
>>> From the latest git version `v8.12-87-g23ddefd', testsuite run by
>>> "nice -n19 make check", using various developement version of other
>>> tools (e.g, sed, awk, make, ...).
>>
>> Thanks for the testing
On 17/06/11 19:34, Jim Meyering wrote:
> Stefano Lattarini wrote:
>> From the latest git version `v8.12-87-g23ddefd', testsuite run by
>> "nice -n19 make check", using various developement version of other
>> tools (e.g, sed, awk, make, ...).
>
> Thanks for the testing and the report.
>
> That wa
one" already, but I'd welcome any feedback,
and won't push right away ;-) ]
>From 9e7ce2c871677422d42ba1616c32ac4f3b9fc002 Mon Sep 17 00:00:00 2001
From: Jim Meyering
Date: Fri, 17 Jun 2011 20:30:10 +0200
Subject: [PATCH] tests: sort-debug-keys: fix a bug with translated
di
On 10/14/10 05:44, Jim Meyering wrote:
>>*val = SIZE_MAX;
>> > + if (debug) /* Note --debug must come before keys to diagnose this.
>> > */
>> > +error (0, 0, _("%" PRIuMAX " is too large, using %zu"), n, *val);
> That does sound like an improvement (that would require commen
On 10/14/2010 06:19 AM, Pádraig Brady wrote:
@@ -3882,6 +3882,8 @@ parse_field_count (char const *string, size_t *val, char
const *msgid)
case LONGINT_OVERFLOW:
case LONGINT_OVERFLOW | LONGINT_INVALID_SUFFIX_CHAR:
*val = SIZE_MAX;
+ if (debug) /* Note --debug must come b
On 14/10/10 13:44, Jim Meyering wrote:
> Pádraig Brady wrote:
>> On 14/10/10 11:06, Jim Meyering wrote:
>>> I noticed that using a field number of SIZE_MAX or larger makes --debug
>>> give an invalid diagnostic:
>>>
>>> $ :|_POSIX2_VERSION=1992
Pádraig Brady wrote:
> On 14/10/10 11:06, Jim Meyering wrote:
>> I noticed that using a field number of SIZE_MAX or larger makes --debug
>> give an invalid diagnostic:
>>
>> $ :|_POSIX2_VERSION=199209 src/sort --debug +$(echo 2^64-1|bc).4 -1.2
>> src/sort: usin
On 14/10/10 11:06, Jim Meyering wrote:
> I noticed that using a field number of SIZE_MAX or larger makes --debug
> give an invalid diagnostic:
>
> $ :|_POSIX2_VERSION=199209 src/sort --debug +$(echo 2^64-1|bc).4 -1.2
> src/sort: using simple byte comparison
> src/sort: o
I noticed that using a field number of SIZE_MAX or larger makes --debug
give an invalid diagnostic:
$ :|_POSIX2_VERSION=199209 src/sort --debug +$(echo 2^64-1|bc).4 -1.2
src/sort: using simple byte comparison
src/sort: obsolescent key `+0 -2' used; consider `-k 1,2' instead
lure right after I checked in,
and thought I had fixed it with 144d6e5f, but misread
the tarball and manual successes as a build success :(
This should hopefully fix it.
sorry,
Pádraig.
diff --git a/tests/misc/sort-debug-keys b/tests/misc/sort-debug-keys
index 0f05025..6714a47 100755
--- a/tests/mis
Hi Pádraig,
I've just noticed this failure:
http://hydra.nixos.org/build/411307/nixlog/1/raw
but don't have time to look at it now.
I suspect that LC_ALL=none is the problem.
FAIL: misc/sort-debug-keys (exit: 1)
sort: key 1 is numeric and span
On 14/05/10 22:47, Pádraig Brady wrote:
> On 14/05/10 22:23, Paul Eggert wrote:
>> Something like the following diagnostic would be far more helpful for
>> users who are not 'sort' experts:
>>
>> sort: obsolescent key `+2 -4' used; consider `-k 3,4' instead
>>
>> Can you please arrange for that?
On 14/05/10 22:23, Paul Eggert wrote:
> On 05/14/10 06:10, Pádraig Brady wrote:
>
>> -if ((1 < (key->random + key->numeric + key->general_numeric +
>> key->month
>> - + key->version + !!key->ignore + key->human_numeric))
>> +if ((1 < (key->random + key_numeric (key) + key->mon
On 05/14/10 06:10, Pádraig Brady wrote:
-if ((1 < (key->random + key->numeric + key->general_numeric + key->month
- + key->version + !!key->ignore + key->human_numeric))
+if ((1 < (key->random + key_numeric (key) + key->month + key->version
+ + !!key->ignore))
On 14/05/10 16:09, Eric Blake wrote:
> On 05/14/2010 07:10 AM, Pádraig Brady wrote:
>>
>> /* The kind of blanks for '-b' to skip in various options. */
>> @@ -375,7 +378,8 @@ Other options:\n\
>>-C, --check=quiet, --check=silent like -c, but do not report first bad
>> line\n\
>>--c
On 05/14/2010 07:10 AM, Pádraig Brady wrote:
> Latest version of the patch attached with new warnings and info.
> Example output...
>
> $ sort --debug -rb -k2n +2 -1b /dev/null
> sort: using `en_US.utf8' sorting rules
> sort: obsolescent key formats used. Consider usin
Latest version of the patch attached with new warnings and info.
Example output...
$ sort --debug -rb -k2n +2 -1b /dev/null
sort: using `en_US.utf8' sorting rules
sort: obsolescent key formats used. Consider using `-k'
sort: key 1 is numeric and spans multiple fields
sort: key 2 has
On 12/05/10 14:55, Eric Blake wrote:
> On 05/12/2010 07:53 AM, Eric Blake wrote:
>> On 05/11/2010 05:39 PM, Pádraig Brady wrote:
>>> The attached patch gives warnings about questionable
>>> option combinations. For example:
>>>
>>> $ sort --debug -rb -k
On 05/12/2010 07:53 AM, Eric Blake wrote:
> On 05/11/2010 05:39 PM, Pádraig Brady wrote:
>> The attached patch gives warnings about questionable
>> option combinations. For example:
>>
>> $ sort --debug -rb -k1,1n /dev/null
>> ! options `-b' are ignored
>&g
On 05/11/2010 05:39 PM, Pádraig Brady wrote:
> The attached patch gives warnings about questionable
> option combinations. For example:
>
> $ sort --debug -rb -k1,1n /dev/null
> ! options `-b' are ignored
> ! option `-r' only applies to last-resort comparison
T
On 12/05/10 00:39, Pádraig Brady wrote:
> The attached patch gives warnings about questionable
> option combinations. For example:
>
> $ sort --debug -rb -k1,1n /dev/null
> ! options `-b' are ignored
> ! option `-r' only applies to last-resort comparison
Oops, The pr
The attached patch gives warnings about questionable
option combinations. For example:
$ sort --debug -rb -k1,1n /dev/null
! options `-b' are ignored
! option `-r' only applies to last-resort comparison
cheers,
Pádraig.
>From 2256de4bdc458ef9e9d92e2009f255bfd3fa2e36 Mon Sep 17 00:00
Perhaps add a --debug option, so users don't write mail like the below
:-)
Kindly add an example to the sort info pages of how to sort
zip utils
xdm x11
cron admin
dpkg admin
lilo admin
menu admin
on the second field. No, -k 2,2 2,2b or whatever doesn't work. Better
yet, why don't you also add a
49 matches
Mail list logo
