Shell(Bash)で「文字クラス」が「文字範囲」よりも優先されるのはなぜですか?

Shell(Bash)で「文字クラス」が「文字範囲」よりも優先されるのはなぜですか?

Linuxのコマンドライン(本 - ページ 47)は次のように述べています。

...正しく設定しないと、期待した結果は生成されないため、[文字範囲]に非常に注意する必要があります。今では、これらの文字クラスを使用せずに文字クラスを使用する必要があります。

それ以外は本では何の理由も提示しません。

質問1:もしそうなら、なぜ正確にキャラクタークラス(例:、、[:alnum:]など)が優先します。[:alpha:][:digit:]文字範囲(例えば、、、[a-z]など)?[A-Z][0-9]

質問2:[:alpha:]、、、​[a-z][A-Z]他の言語の大文字と小文字?同様に[:digit:]、他の言語の数も含まれますか?一致する場合。

(2つの質問があることを知っていますが、この場合IMOとほぼ関連しています。)

ベストアンサー1

bashマンページによると、LC_COLLATE環境変数はHauke Lagingの答えと同様に文字範囲に影響します。

LC_COLLATE この変数は、パス名拡張の結果をソートするときに使用される照合順序を決定し、範囲式、同等クラス、パス名拡張、およびパターン一致のソート順の動作を決定します。

一方、LC_CTYPEキャラクターのカテゴリーに影響を与えるのは次のとおりです。

LC_CTYPEこの変数は、パス名拡張とパターンマッチングの文字解釈と文字クラスの動作を決定します。

それはどういう意味ですか?両方英語、左から右、ラテン文字、アラビア数字の文脈で考えると、このような状況は問題になる可能性があります。

あなたがそれに興味がある場合、または複数のロケールのスクリプトを書いている場合は、ファイルを一致させるときにロケール変数が何であるかを確認するか、完全に一般的な方法で実行していることを確認するのが最善です。

しかし、言語学を勉強しないと、特定の状況を予測することは困難です。

しかし、ラテン語のロケール変更を使用するかどうかはわかりません。注文する文字なので[az]は大丈夫です。そこはい合字と発音区別符号をさまざまな方法で構成するラテンアルファベットの拡張です。しかし、ここにいくつかの実験があります。

mkdir /tmp/test
cd /tmp/test
export LC_CTYPE=de_DE.UTF-8
export LC_COLLATE=de_DE.UTF-8
touch Grüßen
ls G* # This says ‘Grüßen’
ls *[a-z]en # This says nothing!
ls *[a-zß]en # This says ‘Grüßen’
ls Gr[a-z]*en # This says nothing!

これは面白いです。少なくともドイツ語の場合、üのような発音区別記号とßのような合字はラテン文字に縮小されません。 (または私がロケール変更を台無しにしたか!)

もちろん、この方法は不利かもしれません。文字で始まるファイル名を見つけるには、この文字[a-z]*を使用して「A」で始まるファイルに適用します。

おすすめ記事