GNU bug report logs - #12783
info for sort has an illogical example

Previous Next

Package: coreutils;

Reported by: "Kevin O'Gorman" <kogorman <at> gmail.com>

Date: Fri, 2 Nov 2012 00:15:01 UTC

Severity: normal

Tags: moreinfo

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 12783 in the body.
You can then email your comments to 12783 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-coreutils <at> gnu.org:
bug#12783; Package coreutils. (Fri, 02 Nov 2012 00:15:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "Kevin O'Gorman" <kogorman <at> gmail.com>:
New bug report received and forwarded. Copy sent to bug-coreutils <at> gnu.org. (Fri, 02 Nov 2012 00:15:01 GMT) Full text and rfc822 format available.

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

From: "Kevin O'Gorman" <kogorman <at> gmail.com>
To: bug-coreutils <at> gnu.org
Subject: info for sort has an illogical example
Date: Thu, 1 Nov 2012 15:38:40 -0700
[Message part 1 (text/plain, inline)]
This is just a quibble, but I'm really wanting to understand locales and
sort.
In the footnotes of the info page for sort invocation, I find the following
in a footnote:

(reformatted and numbered)
A, In that case, set the `LC_ALL' environment variable to `C'.
B. Note that setting only `LC_COLLATE' has two problems.
B1. First, it is ineffective if `LC_ALL' is also set.
B2. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if
`LC_CTYPE' is unset) is set to an incompatible value.
B2x. For example, you get undefined behavior if `LC_CTYPE' is `ja_JP.PCK'
but `LC_COLLATE' is `en_US.UTF-8'.

The example in B2x is illogical since A and B together mean we're setting
LC_COLLATE to C, not some random value like en_US.UTF-8.
I want to know if LC_COLLATE=C can be messed up by an LC_CTYPE setting, or
anything besides LC_ALL.  I'm writing software that will use sort
extensively in unknown environments, and I'd like to keep all adjustments
as localized as possible.  So far, setting the collating sequence to POSIX
is all that I need; no other locale adjustments.

-- 
Kevin O'Gorman

programmer, n. an organism that transmutes caffeine into software.
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#12783; Package coreutils. (Fri, 02 Nov 2012 18:11:01 GMT) Full text and rfc822 format available.

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

From: Bob Proulx <bob <at> proulx.com>
To: Kevin O'Gorman <kogorman <at> gmail.com>
Cc: 12783 <at> debbugs.gnu.org
Subject: Re: bug#12783: info for sort has an illogical example
Date: Fri, 2 Nov 2012 12:07:28 -0600
Kevin O'Gorman wrote:
> (reformatted and numbered)
> A, In that case, set the `LC_ALL' environment variable to `C'.
> B. Note that setting only `LC_COLLATE' has two problems.
> B1. First, it is ineffective if `LC_ALL' is also set.
> B2. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if
> `LC_CTYPE' is unset) is set to an incompatible value.
> B2x. For example, you get undefined behavior if `LC_CTYPE' is `ja_JP.PCK'
> but `LC_COLLATE' is `en_US.UTF-8'.
> 
> The example in B2x is illogical since A and B together mean we're setting
> LC_COLLATE to C, not some random value like en_US.UTF-8.
> I want to know if LC_COLLATE=C can be messed up by an LC_CTYPE setting, or
> anything besides LC_ALL.  I'm writing software that will use sort
> extensively in unknown environments, and I'd like to keep all adjustments
> as localized as possible.  So far, setting the collating sequence to POSIX
> is all that I need; no other locale adjustments.

I also agree that the above is needlessly disjoint.  It doesn't flow.

Would you be able to suggest an improvement to the wording that would
make it better than the current prose?  Of course a submission as a
patch would be great.  Using git patch submissions is the preferred
format.  But just saying what you think it should say would also be
appreciated.

Bob




Added tag(s) moreinfo. Request was from Bob Proulx <bob <at> proulx.com> to control <at> debbugs.gnu.org. (Mon, 05 Nov 2012 17:52:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-coreutils <at> gnu.org:
bug#12783; Package coreutils. (Tue, 06 Nov 2012 03:36:02 GMT) Full text and rfc822 format available.

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

From: "Kevin O'Gorman" <kogorman <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 12783 <at> debbugs.gnu.org
Subject: Re: bug#12783: info for sort has an illogical example
Date: Mon, 5 Nov 2012 19:31:48 -0800
[Message part 1 (text/plain, inline)]
Looking at a convenient issue of the POSIX standard, I find
http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.htm, and in
particular where it mentions a "precedence order".  It seems that the
interaction of environment variables is not unspecified at all.

I'm guessing that something else was actually meant: the writer perhaps
found it hard to describe in a general way the interaction of a collation
locale with the contents of a file to be sorted if it happens that the
contents were created in another locale and are to be interpreted in the
way they were created.  So, applying LC_COLLATE=C to Chinese big-5 could
well produce a peculiar order of things.

This has already been the case for me.  My data is ASCII, comprising
numeric data and type data, both normal and encoded.  All codes are
printable ASCII and are specifically designed to be sorted based on the
contents of bytes.  This did not work well with LANG=en_US.UTF-8, because
for this data 'a' and 'A' are numbers that differ by 26, but the LANG
setting was treating them as nearly equivalent.  It seems that LC_COLLATE=C
is the correct cure.

If I'm right, it seems that it would be better to rewrite that footnote in
the sort info page something like this:

(1) The collation order used by 'sort' is controlled by environment
variables in accordance with the POSIX specification.  In particular, the
first of the LC_ALL,  LC_COLLATE, and LANG variables that is defined to a
non-null value controls the collation order; in their absence your system
has a default.  If the collation order is incompatible with your data, you
are unlikely to get the desired results.  Often, but not always, setting
and exporting LC_COLLATE=C in your environment is the right choice, but if
your data contains natural language text or proper names the right choice
will agree with the encoding used for the data.  Setting LC_ALL can be
unwise because it can affect many other things as well, such as the
language used for error and help messages. See
http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html or any later
version for more information.

You may also want to change the warning in the output of "sort --help" to
*** WARNING ***
The locale specified by the environment affects sort order. For correct
operation it must be compatible with your data.
Set LC_COLLATE=C to get the traditional sort order that uses native byte
values.


On Fri, Nov 2, 2012 at 11:07 AM, Bob Proulx <bob <at> proulx.com> wrote:

> Kevin O'Gorman wrote:
> > (reformatted and numbered)
> > A, In that case, set the `LC_ALL' environment variable to `C'.
> > B. Note that setting only `LC_COLLATE' has two problems.
> > B1. First, it is ineffective if `LC_ALL' is also set.
> > B2. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if
> > `LC_CTYPE' is unset) is set to an incompatible value.
> > B2x. For example, you get undefined behavior if `LC_CTYPE' is `ja_JP.PCK'
> > but `LC_COLLATE' is `en_US.UTF-8'.
> >
> > The example in B2x is illogical since A and B together mean we're setting
> > LC_COLLATE to C, not some random value like en_US.UTF-8.
> > I want to know if LC_COLLATE=C can be messed up by an LC_CTYPE setting,
> or
> > anything besides LC_ALL.  I'm writing software that will use sort
> > extensively in unknown environments, and I'd like to keep all adjustments
> > as localized as possible.  So far, setting the collating sequence to
> POSIX
> > is all that I need; no other locale adjustments.
>
> I also agree that the above is needlessly disjoint.  It doesn't flow.
>
> Would you be able to suggest an improvement to the wording that would
> make it better than the current prose?  Of course a submission as a
> patch would be great.  Using git patch submissions is the preferred
> format.  But just saying what you think it should say would also be
> appreciated.
>
> Bob
>



-- 
Kevin O'Gorman

programmer, n. an organism that transmutes caffeine into software.
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#12783; Package coreutils. (Tue, 06 Nov 2012 04:24:02 GMT) Full text and rfc822 format available.

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

From: "Kevin O'Gorman" <kogorman <at> gmail.com>
To: Bob Proulx <bob <at> proulx.com>
Cc: 12783 <at> debbugs.gnu.org
Subject: Re: bug#12783: info for sort has an illogical example
Date: Mon, 5 Nov 2012 20:20:46 -0800
[Message part 1 (text/plain, inline)]
One ammendment...  I'd say setting LANG=C is also unwise, and for the same
reason.  make that
- It can be unwise to set LC_ALL or LANG to affect sort order because they
may affect many other things as well, such as the language used for error
and help messages.

On Mon, Nov 5, 2012 at 7:31 PM, Kevin O'Gorman <kogorman <at> gmail.com> wrote:

> Looking at a convenient issue of the POSIX standard, I find
> http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.htm, and in
> particular where it mentions a "precedence order".  It seems that the
> interaction of environment variables is not unspecified at all.
>
> I'm guessing that something else was actually meant: the writer perhaps
> found it hard to describe in a general way the interaction of a collation
> locale with the contents of a file to be sorted if it happens that the
> contents were created in another locale and are to be interpreted in the
> way they were created.  So, applying LC_COLLATE=C to Chinese big-5 could
> well produce a peculiar order of things.
>
> This has already been the case for me.  My data is ASCII, comprising
> numeric data and type data, both normal and encoded.  All codes are
> printable ASCII and are specifically designed to be sorted based on the
> contents of bytes.  This did not work well with LANG=en_US.UTF-8, because
> for this data 'a' and 'A' are numbers that differ by 26, but the LANG
> setting was treating them as nearly equivalent.  It seems that LC_COLLATE=C
> is the correct cure.
>
> If I'm right, it seems that it would be better to rewrite that footnote in
> the sort info page something like this:
>
> (1) The collation order used by 'sort' is controlled by environment
> variables in accordance with the POSIX specification.  In particular, the
> first of the LC_ALL,  LC_COLLATE, and LANG variables that is defined to a
> non-null value controls the collation order; in their absence your system
> has a default.  If the collation order is incompatible with your data, you
> are unlikely to get the desired results.  Often, but not always, setting
> and exporting LC_COLLATE=C in your environment is the right choice, but if
> your data contains natural language text or proper names the right choice
> will agree with the encoding used for the data.  Setting LC_ALL can be
> unwise because it can affect many other things as well, such as the
> language used for error and help messages. See
> http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html or any
> later version for more information.
>
> You may also want to change the warning in the output of "sort --help" to
> *** WARNING ***
> The locale specified by the environment affects sort order. For correct
> operation it must be compatible with your data.
> Set LC_COLLATE=C to get the traditional sort order that uses native byte
> values.
>
>
> On Fri, Nov 2, 2012 at 11:07 AM, Bob Proulx <bob <at> proulx.com> wrote:
>
>> Kevin O'Gorman wrote:
>> > (reformatted and numbered)
>> > A, In that case, set the `LC_ALL' environment variable to `C'.
>> > B. Note that setting only `LC_COLLATE' has two problems.
>> > B1. First, it is ineffective if `LC_ALL' is also set.
>> > B2. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if
>> > `LC_CTYPE' is unset) is set to an incompatible value.
>> > B2x. For example, you get undefined behavior if `LC_CTYPE' is
>> `ja_JP.PCK'
>> > but `LC_COLLATE' is `en_US.UTF-8'.
>> >
>> > The example in B2x is illogical since A and B together mean we're
>> setting
>> > LC_COLLATE to C, not some random value like en_US.UTF-8.
>> > I want to know if LC_COLLATE=C can be messed up by an LC_CTYPE setting,
>> or
>> > anything besides LC_ALL.  I'm writing software that will use sort
>> > extensively in unknown environments, and I'd like to keep all
>> adjustments
>> > as localized as possible.  So far, setting the collating sequence to
>> POSIX
>> > is all that I need; no other locale adjustments.
>>
>> I also agree that the above is needlessly disjoint.  It doesn't flow.
>>
>> Would you be able to suggest an improvement to the wording that would
>> make it better than the current prose?  Of course a submission as a
>> patch would be great.  Using git patch submissions is the preferred
>> format.  But just saying what you think it should say would also be
>> appreciated.
>>
>> Bob
>>
>
>
>
> --
> Kevin O'Gorman
>
> programmer, n. an organism that transmutes caffeine into software.
>



-- 
Kevin O'Gorman

programmer, n. an organism that transmutes caffeine into software.
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#12783; Package coreutils. (Tue, 06 Nov 2012 14:48:02 GMT) Full text and rfc822 format available.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: "Kevin O'Gorman" <kogorman <at> gmail.com>
Cc: 12783 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#12783: info for sort has an illogical example
Date: Tue, 06 Nov 2012 14:44:07 +0000
On 11/06/2012 04:20 AM, Kevin O'Gorman wrote:
> One ammendment...  I'd say setting LANG=C is also unwise, and for the same
> reason.  make that
> - It can be unwise to set LC_ALL or LANG to affect sort order because they
> may affect many other things as well, such as the language used for error
> and help messages.
>
> On Mon, Nov 5, 2012 at 7:31 PM, Kevin O'Gorman <kogorman <at> gmail.com> wrote:
>
>> Looking at a convenient issue of the POSIX standard, I find
>> http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.htm, and in
>> particular where it mentions a "precedence order".  It seems that the
>> interaction of environment variables is not unspecified at all.
>>
>> I'm guessing that something else was actually meant: the writer perhaps
>> found it hard to describe in a general way the interaction of a collation
>> locale with the contents of a file to be sorted if it happens that the
>> contents were created in another locale and are to be interpreted in the
>> way they were created.  So, applying LC_COLLATE=C to Chinese big-5 could
>> well produce a peculiar order of things.
>>
>> This has already been the case for me.  My data is ASCII, comprising
>> numeric data and type data, both normal and encoded.  All codes are
>> printable ASCII and are specifically designed to be sorted based on the
>> contents of bytes.  This did not work well with LANG=en_US.UTF-8, because
>> for this data 'a' and 'A' are numbers that differ by 26, but the LANG
>> setting was treating them as nearly equivalent.  It seems that LC_COLLATE=C
>> is the correct cure.
>>
>> If I'm right, it seems that it would be better to rewrite that footnote in
>> the sort info page something like this:
>>
>> (1) The collation order used by 'sort' is controlled by environment
>> variables in accordance with the POSIX specification.  In particular, the
>> first of the LC_ALL,  LC_COLLATE, and LANG variables that is defined to a
>> non-null value controls the collation order; in their absence your system
>> has a default.  If the collation order is incompatible with your data, you
>> are unlikely to get the desired results.  Often, but not always, setting
>> and exporting LC_COLLATE=C in your environment is the right choice, but if
>> your data contains natural language text or proper names the right choice
>> will agree with the encoding used for the data.  Setting LC_ALL can be
>> unwise because it can affect many other things as well, such as the
>> language used for error and help messages. See
>> http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html or any
>> later version for more information.
>>
>> You may also want to change the warning in the output of "sort --help" to
>> *** WARNING ***
>> The locale specified by the environment affects sort order. For correct
>> operation it must be compatible with your data.
>> Set LC_COLLATE=C to get the traditional sort order that uses native byte
>> values.
>>
>>
>> On Fri, Nov 2, 2012 at 11:07 AM, Bob Proulx <bob <at> proulx.com> wrote:
>>
>>> Kevin O'Gorman wrote:
>>>> (reformatted and numbered)
>>>> A, In that case, set the `LC_ALL' environment variable to `C'.
>>>> B. Note that setting only `LC_COLLATE' has two problems.
>>>> B1. First, it is ineffective if `LC_ALL' is also set.
>>>> B2. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if
>>>> `LC_CTYPE' is unset) is set to an incompatible value.
>>>> B2x. For example, you get undefined behavior if `LC_CTYPE' is
>>> `ja_JP.PCK'
>>>> but `LC_COLLATE' is `en_US.UTF-8'.
>>>>
>>>> The example in B2x is illogical since A and B together mean we're
>>> setting
>>>> LC_COLLATE to C, not some random value like en_US.UTF-8.
>>>> I want to know if LC_COLLATE=C can be messed up by an LC_CTYPE setting,
>>> or
>>>> anything besides LC_ALL.  I'm writing software that will use sort
>>>> extensively in unknown environments, and I'd like to keep all
>>> adjustments
>>>> as localized as possible.  So far, setting the collating sequence to
>>> POSIX
>>>> is all that I need; no other locale adjustments.
>>>
>>> I also agree that the above is needlessly disjoint.  It doesn't flow.
>>>
>>> Would you be able to suggest an improvement to the wording that would
>>> make it better than the current prose?  Of course a submission as a
>>> patch would be great.  Using git patch submissions is the preferred
>>> format.  But just saying what you think it should say would also be
>>> appreciated.

Thanks for cleaning that up Kevin.
Your description is clearer.
I'm not sure we can drop the warning about LC_TYPE though.

While LC_TYPE is _not_ significant to sort order on solaris or GNU/Linux...

$ for e in LANG LC_ALL LC_COLLATE LC_CTYPE; do
    printf "%s\n" B a | echo $(env -i $e=en_US sort)
done
a B
a B
a B
B a

... it may be significant when specifying (multibyte) characters
to skip etc. and thus impacts the sort order in that way.
This is either with common downstream i18n patches or future
multibyte handling in upstream sort.

Unfortunately LC_CTYPE is would up with LC_MESSAGES too (since glibc-2.3.3):
http://www.gnu.org/software/libc/manual/html_node/Charset-conversion-in-gettext.html

thanks,
Pádraig.




Information forwarded to bug-coreutils <at> gnu.org:
bug#12783; Package coreutils. (Wed, 07 Nov 2012 03:00:10 GMT) Full text and rfc822 format available.

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

From: "Kevin O'Gorman" <kogorman <at> gmail.com>
To: Pádraig Brady <P <at> draigbrady.com>
Cc: 12783 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#12783: info for sort has an illogical example
Date: Tue, 6 Nov 2012 18:59:30 -0800
[Message part 1 (text/plain, inline)]
On Tue, Nov 6, 2012 at 6:44 AM, Pádraig Brady <P <at> draigbrady.com> wrote:

> On 11/06/2012 04:20 AM, Kevin O'Gorman wrote:
>
>> One ammendment...  I'd say setting LANG=C is also unwise, and for the same
>> reason.  make that
>> - It can be unwise to set LC_ALL or LANG to affect sort order because they
>> may affect many other things as well, such as the language used for error
>> and help messages.
>>
>> On Mon, Nov 5, 2012 at 7:31 PM, Kevin O'Gorman <kogorman <at> gmail.com>
>> wrote:
>>
>>  Looking at a convenient issue of the POSIX standard, I find
>>> http://pubs.opengroup.org/**onlinepubs/007908799/xbd/**envvar.htm<http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.htm>,
>>> and in
>>> particular where it mentions a "precedence order".  It seems that the
>>> interaction of environment variables is not unspecified at all.
>>>
>>> I'm guessing that something else was actually meant: the writer perhaps
>>> found it hard to describe in a general way the interaction of a collation
>>> locale with the contents of a file to be sorted if it happens that the
>>> contents were created in another locale and are to be interpreted in the
>>> way they were created.  So, applying LC_COLLATE=C to Chinese big-5 could
>>> well produce a peculiar order of things.
>>>
>>> This has already been the case for me.  My data is ASCII, comprising
>>> numeric data and type data, both normal and encoded.  All codes are
>>> printable ASCII and are specifically designed to be sorted based on the
>>> contents of bytes.  This did not work well with LANG=en_US.UTF-8, because
>>> for this data 'a' and 'A' are numbers that differ by 26, but the LANG
>>> setting was treating them as nearly equivalent.  It seems that
>>> LC_COLLATE=C
>>> is the correct cure.
>>>
>>> If I'm right, it seems that it would be better to rewrite that footnote
>>> in
>>> the sort info page something like this:
>>>
>>> (1) The collation order used by 'sort' is controlled by environment
>>> variables in accordance with the POSIX specification.  In particular, the
>>> first of the LC_ALL,  LC_COLLATE, and LANG variables that is defined to a
>>> non-null value controls the collation order; in their absence your system
>>> has a default.  If the collation order is incompatible with your data,
>>> you
>>> are unlikely to get the desired results.  Often, but not always, setting
>>> and exporting LC_COLLATE=C in your environment is the right choice, but
>>> if
>>> your data contains natural language text or proper names the right choice
>>> will agree with the encoding used for the data.  Setting LC_ALL can be
>>> unwise because it can affect many other things as well, such as the
>>> language used for error and help messages. See
>>> http://pubs.opengroup.org/**onlinepubs/007908799/xbd/**envvar.html<http://pubs.opengroup.org/onlinepubs/007908799/xbd/envvar.html>or any
>>> later version for more information.
>>>
>>> You may also want to change the warning in the output of "sort --help" to
>>> *** WARNING ***
>>> The locale specified by the environment affects sort order. For correct
>>> operation it must be compatible with your data.
>>> Set LC_COLLATE=C to get the traditional sort order that uses native byte
>>> values.
>>>
>>>
>>> On Fri, Nov 2, 2012 at 11:07 AM, Bob Proulx <bob <at> proulx.com> wrote:
>>>
>>>  Kevin O'Gorman wrote:
>>>>
>>>>> (reformatted and numbered)
>>>>> A, In that case, set the `LC_ALL' environment variable to `C'.
>>>>> B. Note that setting only `LC_COLLATE' has two problems.
>>>>> B1. First, it is ineffective if `LC_ALL' is also set.
>>>>> B2. Second, it has undefined behavior if `LC_CTYPE' (or `LANG', if
>>>>> `LC_CTYPE' is unset) is set to an incompatible value.
>>>>> B2x. For example, you get undefined behavior if `LC_CTYPE' is
>>>>>
>>>> `ja_JP.PCK'
>>>>
>>>>> but `LC_COLLATE' is `en_US.UTF-8'.
>>>>>
>>>>> The example in B2x is illogical since A and B together mean we're
>>>>>
>>>> setting
>>>>
>>>>> LC_COLLATE to C, not some random value like en_US.UTF-8.
>>>>> I want to know if LC_COLLATE=C can be messed up by an LC_CTYPE setting,
>>>>>
>>>> or
>>>>
>>>>> anything besides LC_ALL.  I'm writing software that will use sort
>>>>> extensively in unknown environments, and I'd like to keep all
>>>>>
>>>> adjustments
>>>>
>>>>> as localized as possible.  So far, setting the collating sequence to
>>>>>
>>>> POSIX
>>>>
>>>>> is all that I need; no other locale adjustments.
>>>>>
>>>>
>>>> I also agree that the above is needlessly disjoint.  It doesn't flow.
>>>>
>>>> Would you be able to suggest an improvement to the wording that would
>>>> make it better than the current prose?  Of course a submission as a
>>>> patch would be great.  Using git patch submissions is the preferred
>>>> format.  But just saying what you think it should say would also be
>>>> appreciated.
>>>>
>>>
> Thanks for cleaning that up Kevin.
> Your description is clearer.
> I'm not sure we can drop the warning about LC_TYPE though.
>
> While LC_TYPE is _not_ significant to sort order on solaris or GNU/Linux...
>
> $ for e in LANG LC_ALL LC_COLLATE LC_CTYPE; do
>     printf "%s\n" B a | echo $(env -i $e=en_US sort)
> done
> a B
> a B
> a B
> B a
>
> ... it may be significant when specifying (multibyte) characters
> to skip etc. and thus impacts the sort order in that way.
> This is either with common downstream i18n patches or future
> multibyte handling in upstream sort.
>
> Unfortunately LC_CTYPE is would up with LC_MESSAGES too (since
> glibc-2.3.3):
> http://www.gnu.org/software/**libc/manual/html_node/Charset-**
> conversion-in-gettext.html<http://www.gnu.org/software/libc/manual/html_node/Charset-conversion-in-gettext.html>
>
> thanks,
> Pádraig.
>

What I wrote is only a suggestion.  As I'm far from expert in these
matters, I'll leave the final form to you all.  Thanks for your work on
coreutils, and your attention to this matter.  I think my work is done here.

-- 
Kevin O'Gorman

programmer, n. an organism that transmutes caffeine into software.
[Message part 2 (text/html, inline)]

Information forwarded to bug-coreutils <at> gnu.org:
bug#12783; Package coreutils. (Tue, 23 Oct 2018 22:15:02 GMT) Full text and rfc822 format available.

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

From: Assaf Gordon <assafgordon <at> gmail.com>
To: Kevin O'Gorman <kogorman <at> gmail.com>, Pádraig Brady
 <P <at> draigbrady.com>
Cc: 12783 <at> debbugs.gnu.org, Bob Proulx <bob <at> proulx.com>
Subject: Re: bug#12783: info for sort has an illogical example
Date: Tue, 23 Oct 2018 16:14:23 -0600
close 12783
stop

(triaging old bugs)

On 06/11/12 07:59 PM, Kevin O'Gorman wrote:
> On Tue, Nov 6, 2012 at 6:44 AM, Pádraig Brady <P <at> draigbrady.com> wrote:
[....]
>> ... it may be significant when specifying (multibyte) characters
>> to skip etc. and thus impacts the sort order in that way.
>> This is either with common downstream i18n patches or future
>> multibyte handling in upstream sort.
>>
>> Unfortunately LC_CTYPE is would up with LC_MESSAGES too (since
>> glibc-2.3.3):
>> http://www.gnu.org/software/**libc/manual/html_node/Charset-**
>> conversion-in-gettext.html<http://www.gnu.org/software/libc/manual/html_node/Charset-conversion-in-gettext.html>
>>
>> thanks,
>> Pádraig.
>>
> 
> What I wrote is only a suggestion.  As I'm far from expert in these
> matters, I'll leave the final form to you all.  Thanks for your work on
> coreutils, and your attention to this matter.  I think my work is done here.

With no further comments in 6 years, I'm closing this bug.

-assaf







bug closed, send any further explanations to 12783 <at> debbugs.gnu.org and "Kevin O'Gorman" <kogorman <at> gmail.com> Request was from Assaf Gordon <assafgordon <at> gmail.com> to control <at> debbugs.gnu.org. (Tue, 30 Oct 2018 04:29:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 27 Nov 2018 12:24:13 GMT) Full text and rfc822 format available.

This bug report was last modified 5 years and 123 days ago.

Previous Next


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