Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #14880 > unrolled thread

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

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Bash removes unrequested characters in bracket expressions (not a range). Chet Ramey <chet.ramey@case.edu> - 2018-11-28 09:09 -0800

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

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/

[toc] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web