Re: collation with glibc

[Valeriy E. Ushakov]

On Thu, Apr 20, 2000 at 10:24:22 +1000, David Duffy wrote:

> When I wrote to the maintainer of GNU sort about this behaviour, he
> suggested setting the locale to "POSIX".  This also avoids the
> problem (the Lout manual is produced in 6 iterations by 3.17
> running under Mandrake 7.0).  But should one encourage POSIX compliance
> too much? ;)

Setting LC_COLLATE to POSIX (or, which is equivalent, to C) have the
effect of turning strcoll off into strcpy, and so has the same effect
as lout -l option.

This will make User's Guide to converge.  This will also make English
users happy.

Of course this is totally unacceptable for people writing documents in
any other language, where culturally expected collation order is not
asciibetical.

Also note, that sort(1) is as good a victim as Lout is in this case,
as it just uses strcoll(3) as well when supplied -l option (NB, this
is sort's -l options which means to turn locale aware collation on -
just opposite of lout -l, which turns collation off).

One can try to make a custom collation rules changing weights like, e.g.

    <HT>    IGNORE;IGNORE;IGNORE;<HT>

into

    <HT>    <HT>;IGNORE;IGNORE;IGNORE

if I get the format and semantics correctly from the casual glance at
glibc-localedata.  This will give character, <HT> in this case,
primary weight and allow it to compete with alphanumerics.

As I have already written, Lout is partially responsible for the
problem as well.  It makes a shortcut by directly comparing

        PRIMARYA\tSECONDARYA\tRESTA
        PRIMARYB\tSECONDARYB\tRESTB

SY, Uwe
-- 
address@hidden                         |       Less bread!
http://www.ptc.spbu.ru/~uwe/            |       More taxes!