bash运算符=〜尊重语言环境吗？

Question

按照bash手册的Conditional Constructs部分所述的bash运算符=~是否尊重语言环境？

文档使用POSIX扩展正则表达式来暗示它：

  

运算符右侧的字符串被视为扩展正则表达式并相应匹配（如在regex3中）

POSIX扩展正则表达式联机帮助页man 7 regex描述了它们与语言环境相关。特别是关于括号表达式，它说：

  

如果列表中的两个字符由＆＃39; - ＆＃39;分隔，则这是整理顺序中这两个（包括）之间的全部字符的简写，例如＆＃34; [ 0-9]＆＃34;在ASCII中匹配任何十进制数字。 ...范围依赖于整理顺序，便携式程序应该避免依赖它们。

所有这些都告诉我，与bash =~运算符一起使用的正则表达式应该尊重语言环境;但是我的测试似乎没有证明这一点：

$ export LANG=en_US
$ export LC_COLLATE=en_US
$ [[ B =~ [A-M] ]] && echo matched || echo unmatched
matched
$ [[ b =~ [A-M] ]] && echo matched || echo unmatched
unmatched

我希望最后一个命令也回显matched，因为en_US的整理顺序为aAbBcCdD...，而ABCD...abcd...中的C序列则相反（ASCII）语言环境。

我是否错误地设置了我的区域设置？ bash没有为POSIX扩展正则表达式正确设置语言环境以使用语言环境吗？

根据马科斯的答案进行了一些实验：

在en_US区域设置中，[a-M]显然匹配任何小写字符a到z以及任何大写字符A到M。这会建议使用abcd...ABCD...而不是aAbBcCdD...的整理顺序。使用C切换到[a-M]区域设置将导致条件构造的退出代码为2，而不是0或1。这表示无效的正则表达式，这在整理顺序C之后的a区域设置M中有意义。

因此，locale肯定会在POSIX扩展正则表达式中使用。但是括号表达式不遵循我期望的整理顺序。括号表达式是否可能使用除整理顺序之外的其他内容？

edit1：已更新，以使用实际正确的en_US整理顺序 edit2：进一步增加了调查结果。

Answer 1

它实际上是aAbB ......而不是AaBb 试试这个：touch {a..z}; touch {A..Z}; ls -1 | sort。
看到？

所以

$ [[ a =~ [a-M] ]] && echo matched || echo unmatched
matched
$ [[ A =~ [a-M] ]] && echo matched || echo unmatched
matched