On 11/28/18 2:45 AM, Bize Ma wrote:
> Chet Ramey (<[email protected] <mailto:[email protected]>>) wrote:
>
> On 11/24/18 2:32 PM, Chet Ramey wrote:
>
> >> But IMO locale collation should not be used for an explicit list.
> >
> > Collation order is used for each individual character in a bracket
> > expression when compared against the string, as posix specifies.
>
>
> Yes, values resulting from a glob expansion should be compared with strcoll.
>
> How many characters should there be in a range like [0-0] ?
> Or to be more precise: in a [0] bracket expression? one?
There should be one character ("0") that matches as many characters as
collate equal to the character "0", as per the POSIX quote in my previous
message.
>
> If I were you, I would file a bug report with Debian against wcscoll.
>
>
> And I would be told that wcscoll is doing what the collation file 14651 is
> telling it to do.
Sure.
>
> And, that in any case, that file has been updated in glib2.8 anyway.
That should fix the problem without forcing applications to attempt to
impose a total ordering even when strcoll/wcscoll returns 0.
> It returns 0 (equal) for L"٠" and L"0" without setting errno. That's
> clearly a problem with wcscoll (if the character isn't valid in the
> current
> locale) or the locale definition.
>
>
> Both characters collate to the same position as I have already explained.
Yes, so the locale definition files imposing a total ordering will be a
clear improvement.
>
> I don't follow you about what you mean with: /(if the character isn't valid
> in the current
> locale)./
There are codepoints that correspond to characters in one locale but don't
map to a valid character in another.
Chet
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU [email protected] http://tiswww.cwru.edu/~chet/
