Por que [AZ] corresponde a letras minúsculas no bash?

Em todos os shells que eu conheço, rm [A-Z]*remove todos os arquivos que começam com uma letra maiúscula, mas com o bash isso remove todos os arquivos que começam com uma letra.

Como esse problema existe no Linux e Solaris com o bash-3 e o bash-4, não pode ser um bug causado por um correspondente de padrão de bugs na libc ou por uma definição de localidade com configuração incorreta.

Esse comportamento estranho e arriscado é intencional ou é apenas um bug que existe sem correção há muitos anos?

Observe que, ao usar expressões de intervalo como [az], podem ser incluídas letras do outro caso, dependendo da configuração de LC_COLLATE.

LC_COLLATE é uma variável que determina a ordem de intercalação usada ao classificar os resultados da expansão do nome do caminho e determina o comportamento das expressões de intervalo, classes de equivalência e sequências de intercalação na expansão do nome do caminho e na correspondência de padrões.

Considere o seguinte:

$ touch a A b B c C x X y Y z Z
$ ls
a  A  b  B  c  C  x  X  y  Y  z  Z
$ echo [a-z] # Note the missing uppercase "Z"
a A b B c C x X y Y z
$ echo [A-Z] # Note the missing lowercase "a"
A b B c C x X y Y z Z

Observe que quando o comando echo [a-z]é chamado, a saída esperada seria todos os arquivos com caracteres minúsculos. Além disso, com echo [A-Z], arquivos com caracteres maiúsculos seriam esperados.

Agrupamentos padrão com localidades, como en_USa seguinte ordem:

aAbBcC...xXyYzZ

• Entre ae z(in [a-z]) são TODAS as letras maiúsculas, exceto Z.
• Entre Ae Z(in [A-Z]) são TODAS as letras minúsculas, exceto a.

Vejo:

     aAbBcC[...]xXyYzZ
     |              |
from a      to      z

     aAbBcC[...]xXyYzZ
      |              |
from  A     to       Z

Se você alterar a LC_COLLATEvariável para Ca aparência esperada:

$ export LC_COLLATE=C
$ echo [a-z]
a b c x y z
$ echo [A-Z]
A B C X Y Z

Portanto, não é um bug , é um problema de agrupamento .

Em vez de expressões de intervalo, você pode usar classes de caracteres definidas no POSIX , como upperou lower. Eles também funcionam com LC_COLLATEconfigurações diferentes e até com caracteres acentuados :

$ echo [[:lower:]]
a b c x y z à è é
$ echo [[:upper:]]
A B C X Y Z

[A-Z]in bashcorresponde a todos os elementos de intercalação (caracteres, mas também podem ser sequências de caracteres, como Dsznas localidades húngaras) que são classificadas após Ae classificadas antes Z. No seu local, cprovavelmente classifica entre B e C.

$ printf '%s\n' A a á b B c C Ç z Z Ẑ | sort
a
A
á
b
B
c
C
Ç
z
Z
Ẑ

Então, cou zseria correspondido por [A-Z], mas não Ẑou a.

$ printf '%s\n' A a á b B c C Ç z Z Ẑ |
pipe>  bash -c 'while IFS= read -r x; do case $x in [A-Z]) echo "$x"; esac; done'
A
á
b
B
c
C
Ç
z
Z

No código C, o pedido seria:

$ printf '%s\n' A a á b B c C Ç z Z Ẑ | LC_COLLATE=C sort
A
B
C
Z
a
b
c
z
Ç
á
Ẑ

Então [A-Z]iria corresponder A, B, C, Z, mas não Çe ainda não Ẑ.

Se você deseja combinar com letras maiúsculas (em qualquer script), você pode usá-lo [[:upper:]]. Não existe uma maneira incorporada bashde combinar apenas letras maiúsculas no script latino (exceto listando-as individualmente).

Se você quiser combinar com o Ade Z Inglês letras sem diacríticos, você pode usar [A-Z]ou [[:upper:]]mas no Clocal (assumindo que os dados não são codificados em conjuntos de caracteres como BIG5 ou GB18030, que tem vários personagens cujas codificação contém a codificação dessas cartas) ou lista eles individualmente ( [ABCDEFGHIJKLMNOPQRSTUVWXYZ]).

Observe que há alguma variação entre as conchas.

For zsh, bash -O globasciiranges(opção de nome estranho introduzida no bash-4.3), schily-she yash, [A-Z]corresponde aos caracteres cujo ponto de código está entre o de Ae o de Z, portanto seria equivalente ao comportamento do código de bashidioma C.

Para cinzas, mksh e cascas antigas, o mesmo que zshacima, mas limitado a conjuntos de caracteres de byte único. Ou seja, em um código de idioma UTF-8, por exemplo, [É-Ź]não corresponderia Ó, mas, como isso [<c3><89>-<c5><b9>], corresponderia aos valores de bytes 0x89 a 0xc5!

ksh93comporta-se como bashexceto que trata como intervalos de casos especiais cujas extremidades começam com letras minúsculas ou maiúsculas. Nesse caso, ele corresponde apenas aos elementos de intercalação que se classificam entre essas extremidades, mas que são (ou o primeiro caractere para elementos de intercalação de vários caracteres) também em minúsculas (ou maiúsculas, respectivamente). Portanto [A-Z], haveria correspondência em É, mas não em, ecomo ea classificação entre Ae Zmas não é maiúscula como Ae Z.

Para fnmatch()padrões (como em find -name '[A-Z]') ou expressões regulares do sistema (como em grep '[A-Z]'), isso depende do sistema e da localidade. Por exemplo, em um sistema GNU aqui, [A-Z]não corresponde no código xdo en_GB.UTF-8idioma, mas no th_TH.UTF-8. Não está claro para mim quais informações são usadas para determinar isso, mas aparentemente são baseadas em uma tabela de pesquisa derivada dos dados do código de idioma LC_COLLATE ).

Todos os comportamentos são permitidos pelo POSIX, pois o POSIX deixa o comportamento dos intervalos não especificados em códigos de idioma que não sejam o código C. Agora podemos discutir sobre os benefícios de cada abordagem.

bashA abordagem de faz muito sentido [C-G], pois queremos que os personagens entre Ce G. E usar a ordem de classificação do usuário para o que determina o que é intermediário é a abordagem mais lógica.

Agora, o problema é que isso quebra as expectativas de muitas pessoas, especialmente aquelas que estão acostumadas com o comportamento tradicional do pré-Unicode, mesmo nos dias anteriores à internacionalização. Embora, para um usuário normal, faça sentido que [C-I]inclua hcomo a hletra está entre Ce Ie que [A-g]não inclua Z, é uma questão diferente para as pessoas que lidam com o ASCII apenas por décadas.

Esse bashcomportamento também é diferente do [A-Z]intervalo correspondente em outras ferramentas GNU, como nas expressões regulares do GNU (como em grep/ sed...) ou fnmatch()como em find -name.

Isso também significa que o que [A-Z]corresponde varia de acordo com o ambiente, com o sistema operacional e com a versão do sistema operacional. O fato de [A-Z]corresponder Á, mas não Ź também é subótimo.

Para zsh/ yash, usamos uma ordem de classificação diferente. Em vez de confiar na noção de ordem de caracteres do usuário, usamos os valores do código do ponto de caractere. Isso tem o benefício de ser fácil de entender, mas de um ponto prático de poucos, fora do ASCII, não é muito útil. [A-Z]corresponde às 26 letras maiúsculas em inglês dos EUA, [0-9]corresponde aos dígitos decimais. Existem pontos de código no Unicode que seguem a ordem de alguns alfabetos, mas isso não é generalizado e não pode ser generalizado, pois pessoas diferentes que usam o mesmo script não necessariamente concordam com a ordem das letras.

Para shells e mksh tradicionais, traço, está quebrado (agora que a maioria das pessoas usa caracteres de vários bytes), mas principalmente porque ainda não têm suporte para vários bytes. A adição de suporte de vários bytes a shells como bashe zshtem sido um grande esforço e ainda está em andamento. yash(shell japonês) foi projetado inicialmente com suporte a vários bytes desde o início.

A abordagem do ksh93 tem o benefício de ser consistente com as expressões regulares do sistema ou fnmatch () (ou pelo menos parece ser pelo menos nos sistemas GNU). Lá, isso não quebra a expectativa de algumas pessoas, pois [A-Z]não inclui letras minúsculas, [A-Z]inclui É(e Á, mas não Ź). Não é consistente com sortou geralmente strcoll()ordem.

Ele foi planejado e documentado na bashdocumentação, seção de correspondência de padrões . A expressão de intervalo [X-Y]incluirá todos os caracteres entre Xe Yusando a sequência de intercalação e o conjunto de caracteres do código de idioma atual:

LC_ALL=en_US.utf8 bash -c 'case b in [A-Z]) echo yes; esac' 
yes

Você pode ver, bclassificado entre Ae Zno en_US.utf8código do idioma.

Você tem algumas opções para evitar esse comportamento:

# Setting LC_ALL or LC_COLLATE to C
LC_ALL=C bash -c 'echo [A-Z]*'

# Or using POSIX character class
LC_ALL=C bash -c 'echo [[:upper:]]*'

ou ativar globasciiranges(com bash 4.3 e acima):

bash -O globasciiranges -c 'echo [A-Z]*'

Eu observei esse comportamento em uma nova instância do Amazon EC2. Como o OP não ofereceu um MCVE , postarei um:

$ cd $(mktemp -d)
$ touch foo
$ echo [A-Z]*     # prepare for a surprise!
foo

$ echo $BASH_VERSION
4.1.2(1)-release
$ uname -a
Linux spinup-tmp12 3.14.27-25.47.amzn1.x86_64 #1 SMP Wed Dec 17 18:36:15 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux

$ env | grep LC_  # no locale, let's set one
$ LC_ALL=C
$ echo [A-Z]*
[A-Z]*

$ unset LC_ALL    # ok, good. what if we go back to no locale?
$ echo [A-Z]*
foo

Portanto, não ter meu LC_*conjunto leva o lançamento do bash 4.1.2 (1) no Linux para produzir um comportamento aparentemente estranho. Posso alternar com segurança o comportamento ímpar definindo e desabilitando as respectivas variáveis ​​de localidade. Sem surpresa, esse comportamento parece consistente através da exportação:

$ export LC_ALL=C
$ bash
$ echo [A-Z]*
[A-Z]*
$ exit
$ echo $SHLVL
1
$ unset LC_ALL
$ bash
$ echo [A-Z]*
foo

Enquanto estou vendo o bash se comportar quando Stéphane "Shellshock" Chazelas respondeu , acho que a documentação do bash sobre correspondência de padrões é buggy:

Por exemplo, no código de idioma C padrão , '[a-dx-z]' é equivalente a '[abcdxyz]'

Eu li essa frase (ênfase minha) como "se as variáveis ​​de localidade relevantes não estiverem definidas, o bash será padronizado como a localidade C". Bash não parece estar fazendo isso. Em vez disso, parece estar padronizado para uma localidade em que os caracteres são classificados em ordem de dicionário com dobras diacríticas:

$ echo [A-E]*
[A-E]*
$ echo [A-F]*
foo
$ touch "évocateur"
$ echo [A-F]*
foo évocateur

Eu acho que seria bom para o bash documentar como ele se comportará quando LC_*(especificamente LC_CTYPEe LC_COLLATE) estiver indefinido. Mas enquanto isso, vou compartilhar um pouco de sabedoria :

... você precisa ter muito cuidado com [intervalos de caracteres] porque eles não produzirão os resultados esperados, a menos que sejam configurados corretamente. Por enquanto, você deve evitar usá-los e usar classes de caracteres.

e

Se você é realmente adequado e / ou está criando scripts para um ambiente com várias localidades, provavelmente é melhor garantir que você saiba quais são as suas variáveis ​​de local quando estiver fazendo a correspondência de arquivos ou se está codificando em um maneira completamente genérica.

Atualização Com base no comentário do @ G-Man, vamos analisar mais profundamente o que está acontecendo:

$ env | grep LANG
LANG=en_US.UTF-8

Ah ha! Isso explica o agrupamento visto anteriormente. Vamos remover todas as variáveis ​​de localidade:

$ unset LANG LANGUAGE LC_ALL
$ env | grep 'LC_|LANG'
$ echo [A-Z]*
[A-Z]*

Aqui vamos nós. Agora, o bash opera de forma consistente com relação à documentação neste sistema Linux. Se qualquer uma das variáveis de região são definidos ( LANGUAGE, LANG, LC_COLLATE, LC_CTYPE, LC_ALL, etc.), em seguida, Bash usa aqueles de acordo com o manual. Caso contrário, o bash volta para C.

O FAQ do bash do Wooledge tem o seguinte a dizer:

Em sistemas GNU recentes, as variáveis ​​são usadas nesta ordem. Se LANGUAGE estiver definido, use-o, a menos que LANG esteja definido como C, nesse caso, LANGUAGE será ignorado. Além disso, alguns programas simplesmente não usam LANGUAGE. Caso contrário, se LC_ALL estiver definido, use isso. Caso contrário, se a variável LC_ * específica que cobre esse uso estiver configurada, use isso. (Por exemplo, LC_MESSAGES cobre mensagens de erro.) Caso contrário, use LANG.

Portanto, o aparente problema, tanto na operação quanto na documentação, pode ser explicado analisando a soma total de todas as variáveis ​​de localização do código do idioma.

A localidade pode alterar quais caracteres são correspondidos [A-Z]. Usar

(LC_ALL=C; rm [A-Z]*)

para eliminar a influência. (Eu usei um subshell para localizar a alteração).

Como já foi dito, esse é um problema de "ordem de classificação".

O intervalo az pode conter letras maiúsculas em alguns locais:

     aAbBcC[...]xXyYzZ
     |              |
from a      to      z

A solução correta desde o bash 4.3 é definir a opção globasciiranges:

shopt -s globasciiranges

para fazer festa de agir como se LC_COLLATE=Cfoi definido no glob faixas ing.

Parece que encontrei a resposta certa para minha própria pergunta:

O Bash é um buggy, pois não gerencia seu próprio local. Portanto, definir LC_ * em um processo bash não tem efeito nesse processo de shell.

Se você definir LC_COLLATE = C e depois iniciar outro bash, a globbing funcionará conforme o esperado no novo processo do bash.