Pourquoi [AZ] correspond-il aux minuscules en bash?

Dans tous les shells dont je suis au courant, rm [A-Z]*supprime tous les fichiers commençant par une lettre majuscule, mais avec bash, tous les fichiers commençant par une lettre sont supprimés.

Comme ce problème existe sous Linux et Solaris avec bash-3 et bash-4, il ne peut pas s'agir d'un bogue causé par un matcher de motif de buggy dans libc ou par une définition de paramètres régionaux mal configurée.

Ce comportement étrange et risqué est-il prévu ou s'agit-il simplement d'un bug qui existe depuis plusieurs années?

Notez que lorsque vous utilisez des expressions de plage telles que [az], les lettres de l'autre cas peuvent être incluses, en fonction du paramètre de LC_COLLATE.

LC_COLLATE est une variable qui détermine l'ordre de classement utilisé lors du tri des résultats de l'expansion du chemin, et détermine le comportement des expressions de plage, des classes d'équivalence et des séquences de classement lors du développement du chemin et de la correspondance de motifs.

Considérer ce qui suit:

$ 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

Notez que lorsque la commande echo [a-z]est appelée, la sortie attendue serait tous les fichiers avec des caractères minuscules. En outre, avec echo [A-Z], les fichiers avec des caractères majuscules sont attendus.

Les classements standard avec des paramètres régionaux, tels que en_USl'ordre suivant:

aAbBcC...xXyYzZ

• Entre aet z(en [a-z]) sont TOUTES les lettres majuscules, sauf pour Z.
• Entre Aet Z(en [A-Z]) sont TOUTES les lettres minuscules, à l'exception de a.

Voir:

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

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

Si vous modifiez la LC_COLLATEvariable pour Cqu'elle ressemble comme prévu:

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

Donc, ce n'est pas un bug , c'est un problème de classement .

Au lieu des expressions de plage, vous pouvez utiliser les classes de caractères définies par POSIX , telles que upperou lower. Ils fonctionnent aussi avec différentes LC_COLLATEconfigurations et même avec des caractères accentués :

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

[A-Z]in bashcorrespond à tous les éléments de classement (les caractères mais appellent également une séquence de caractères comme Dszdans les paramètres régionaux hongrois) qui trient après Aet trient avant Z. Dans votre région, les ctris probablement entre B et C.

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

Donc cou zserait assorti par [A-Z], mais pas Ẑ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

Dans les paramètres régionaux C, l'ordre serait:

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

Alors [A-Z]correspondrait A, B, C, Z, mais pas Çet toujours pas Ẑ.

Si vous voulez faire correspondre les lettres majuscules (dans n'importe quel script), vous pouvez utiliser à la [[:upper:]]place. Il n'y a pas de moyen intégré de bashfaire correspondre uniquement les lettres majuscules dans le script latin (sauf en les listant individuellement).

Si vous voulez faire correspondre l' Aà Z anglais lettres sans signes diacritiques, vous pouvez utiliser [A-Z]ou [[:upper:]]mais dans le Clieu ( en supposant que les données ne sont pas codées dans les jeux de caractères comme GRAND5 ou GB18030 qui a plusieurs caractères dont le codage contient l'encodage de ces lettres) ou de la liste individuellement ( [ABCDEFGHIJKLMNOPQRSTUVWXYZ]).

Notez qu'il existe certaines variations entre les coquilles.

For zsh, bash -O globasciiranges(option étrangement nommée introduite dans bash-4.3), schily-shet yash, les [A-Z]correspondances sur les caractères dont le point de code est compris entre celui de Aet celui de Z, seraient donc équivalentes au comportement de bashla locale C.

Pour les cendres, les mksh et les coquilles anciennes, comme zshci-dessus, mais limité aux jeux de caractères codés sur un octet. C’est-à-dire que, dans un environnement local UTF-8 par exemple, [É-Ź]ne correspondrait pas à Ó, mais puisque cela [<c3><89>-<c5><b9>]correspond aux valeurs d’octets 0x89 à 0xc5!

ksh93se comporte comme bashsi ce n’était les cas spéciaux dont les extrémités commençaient par des lettres minuscules ou des lettres majuscules. Dans ce cas, seuls les éléments de classement triés entre ces extrémités sont appariés, mais qui sont (ou leur premier caractère pour les éléments de classement multi-caractères) également en minuscule (ou majuscule, respectivement). Donc, [A-Z]il y aurait correspondance É, mais pas ecomme etrie entre Aet Zmais n'est pas comme majuscule Aet Z.

Pour les fnmatch()modèles (comme dans find -name '[A-Z]') ou les expressions régulières système (comme dans grep '[A-Z]'), cela dépend du système et des paramètres régionaux. Par exemple, sur un système GNU ici, [A-Z]ne correspond pas xà l' en_GB.UTF-8environnement local, mais au contraire th_TH.UTF-8. Les informations utilisées pour déterminer cela ne sont pas claires, mais elles sont apparemment basées sur une table de consultation dérivée des données de paramètres régionaux LC_COLLATE ).

POSIX autorise tous les comportements, car POSIX laisse le comportement des plages non spécifiées dans des paramètres régionaux autres que les paramètres régionaux C. Nous pouvons maintenant discuter des avantages de chaque approche.

bashCette approche a beaucoup de sens car [C-G]nous voulons que les personnages se situent entre Cet G. Et l'utilisation de l'ordre de tri de l'utilisateur pour déterminer ce qui est intermédiaire est l'approche la plus logique.

Le problème, c’est que cela répond aux attentes de beaucoup de gens, en particulier de ceux qui sont habitués au comportement traditionnel du pré-Unicode, même des jours qui précédaient l’internationalisation. Bien que d'un utilisateur normal, il est logique mai qui [C-I]comprend hque la hlettre est entre Cet Iet [A-g]ne comprend pas Z, il est une autre affaire pour les personnes ayant traité avec ASCII seulement pendant des décennies.

Ce bashcomportement est également différent de la [A-Z]correspondance de plage dans d'autres outils GNU, comme dans les expressions régulières GNU (comme dans grep/ sed...) ou fnmatch()comme dans find -name.

Cela signifie également que ce qui [A-Z]correspond à l'environnement, au système d'exploitation et à la version du système d'exploitation. Le fait de [A-Z]correspondre à Á mais pas à Ź est également sous-optimal.

Pour zsh/ yash, nous utilisons un ordre de tri différent. Au lieu de s’appuyer sur la notion d’ordre des caractères de l’utilisateur, nous utilisons les valeurs de code des points de caractère. Cela a l'avantage d'être facile à comprendre, mais d'un point de vue pratique, en dehors de l'ASCII, ce n'est pas très utile. [A-Z]correspond aux 26 lettres majuscules anglais anglais, [0-9]correspond aux chiffres décimaux. Il existe des points de code dans Unicode qui suivent l'ordre de certains alphabets mais ce n'est pas généralisé et ne peut pas être généralisé car de toute façon, différentes personnes utilisant un même script ne sont pas nécessairement d'accord sur l'ordre des lettres.

Pour les shells traditionnels et mksh, dash, c'est brisé (maintenant que la plupart des gens utilisent des caractères multi-octets), mais principalement parce qu'ils ne disposent pas encore d'une prise en charge multi-octets. Ajout d'un support multi-octets à coquilles comme bashet zsha été un énorme effort et est toujours en cours. yash(un shell japonais) a été initialement conçu avec une prise en charge multi-octets.

L'approche de ksh93 présente l'avantage d'être compatible avec les expressions régulières du système ou avec fnmatch () (ou du moins, du moins sur les systèmes GNU). Là, cela ne brise pas l'attente de certaines personnes, car il [A-Z]n'inclut pas les lettres minuscules, [A-Z]inclut É(et Á, mais pas). Ce n'est pas compatible avec sortou généralement l' strcoll()ordre.

Il est prévu et documenté dans la bashdocumentation, section de correspondance de modèle . L'expression de plage [X-Y]comprendra tous les caractères compris entre Xet Yutilisant la séquence et le jeu de caractères de la locale en cours:

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

Vous pouvez voir, btriés entre Aet Zdans les en_US.utf8paramètres régionaux.

Vous avez plusieurs choix pour empêcher ce problème:

# 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 activer globasciiranges(à partir de 4.3 et plus):

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

J'ai observé ce comportement sur une nouvelle instance Amazon EC2. Puisque le PO n’a pas offert de MCVE , je vais en poster un:

$ 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

Donc, ne pas avoir mon LC_*jeu entraîne la sortie de bash 4.1.2 (1) sur Linux pour produire un comportement apparemment étrange. Je peux basculer de manière fiable le comportement étrange en définissant et en désactivant les variables de paramètres régionaux respectives. Sans surprise, ce comportement semble être cohérent lors de l'exportation:

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

Bien que bash se comporte comme si Stéphane "Shellshock" répondait Chazelas , je pense que la documentation de bash sur la correspondance des modèles est un buggy:

Par exemple, dans les paramètres régionaux C par défaut , "[a-dx-z]" est équivalent à "[abcdxyz]".

J'ai lu cette phrase (l'emphase mienne) comme suit: "si les variables de paramètres régionaux pertinentes ne sont pas définies, bash utilisera par défaut les paramètres régionaux C". Bash ne semble pas le faire. Au lieu de cela, il semble que les paramètres régionaux par défaut soient triés dans l'ordre du dictionnaire avec le repliement diacritique:

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

Je pense qu'il serait bon que bash documente comment il se comportera quand LC_*(spécifiquement LC_CTYPEet LC_COLLATE) ne sont pas définis. Mais dans le même temps, je partagerai un peu de sagesse :

... vous devez être très prudent avec les [plages de caractères], car elles ne produiront pas les résultats attendus si elles ne sont pas correctement configurées. Pour le moment, évitez de les utiliser et utilisez plutôt des classes de caractères.

et

Si vous êtes vraiment approprié et / ou que vous écrivez des scripts pour un environnement multi-local, il est probablement préférable de vous assurer de connaître vos variables locales lorsque vous faites correspondre les fichiers, ou bien de coder dans un fichier. manière complètement générique.

Mise à jour Sur la base du commentaire de @ G-Man, examinons ce qui se passe:

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

Ah ah! Cela explique le classement vu précédemment. Supprimons toutes les variables de locale:

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

Nous y voilà. Maintenant, bash fonctionne de manière cohérente en ce qui concerne la documentation sur ce système Linux. Si l' une des variables locale sont définies ( LANGUAGE, LANG, LC_COLLATE, LC_CTYPE, LC_ALL, etc.) , puis Bash utilise celles selon son manuel. Sinon, bash retombe à C.

La FAQ de Wooledge bash dit ceci:

Sur les systèmes GNU récents, les variables sont utilisées dans cet ordre. Si LANGUAGE est défini, utilisez-le, sauf si LANG est défini sur C, auquel cas LANGUAGE est ignoré. En outre, certains programmes n’utilisent tout simplement pas LANGUE. Sinon, si LC_ALL est défini, utilisez-le. Sinon, si la variable LC_ * spécifique qui couvre cette utilisation est définie, utilisez-la. (Par exemple, LC_MESSAGES couvre les messages d'erreur.) Sinon, utilisez LANG.

Ainsi, le problème apparent, à la fois en termes de fonctionnement et de documentation, peut être expliqué en regardant la somme totale de toutes les variables de contrôle des paramètres régionaux.

Les paramètres régionaux peuvent modifier les caractères correspondants [A-Z]. Utilisation

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

éliminer l'influence. (J'ai utilisé un sous-shell pour localiser le changement).

Comme cela a déjà été dit, il s’agit d’un problème d’ordre de classement.

La plage az peut contenir des lettres majuscules dans certaines langues:

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

La solution correcte depuis bash 4.3 consiste à définir l’option suivante globasciiranges:

shopt -s globasciiranges

faire que bash agisse comme si elle LC_COLLATE=Cavait été définie dans des gammes globales .

Il semble que j'ai trouvé la bonne réponse à ma propre question:

Bash est un bug car il ne gère pas ses propres paramètres régionaux. Donc, définir LC_ * dans un processus bash est sans effet dans ce processus shell.

Si vous définissez LC_COLLATE = C, puis démarrez un autre bash, la suppression fonctionne comme prévu dans le nouveau processus bash.