Re: Bash removes unrequested characters in bracket expressions (not a range).

[Chet Ramey]

On 11/28/18 2:45 AM, Bize Ma wrote:
> Chet Ramey (<chet.ramey@case.edu <mailto:chet.ramey@case.edu>>) 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    chet@case.edu    http://tiswww.cwru.edu/~chet/