Re: Merkwürdige Locale-Effekte in Bash (war: Re: Wohin mit den eigenen init-Skripten?)
Am Dienstag, 16. Februar 2016, 11:24:26 CET schrieb Martin Klaiber:
> Martin Steigerwald <martin@lichtvoll.de> wrote:
> > Krass! Wie kaputt ist das denn?
>
> Tja, ist es kaputt? Das ist die Frage. Das Verhalten ist ja seit Jahren
> bekannt und damit vermutlich auch den bash-Entwicklern. Der Artikel von
> Allen ist aus 2003, der Artikel in comp.unix.shell aus 2006.
>
> In man bash steht:
>
> [...] Matches any one of the enclosed characters. A pair of
> characters separated by a hyphen denotes a range expression;
> any character that sorts between those two characters,
> inclusive, using the current locale's collating sequence and
> character set, is matched.
>
> und weiter:
>
> The sorting order of characters in range expressions is
> determined by the current locale and the value of the
> LC_COLLATE shell variable, if set.
>
> Da steht also, dass zwei Zeichen, getrennt durch einen Bindestrich,
> einen Bereich angeben und alle Zeichen matchen, die zwischen diesen
> Zeichen einsortiert sind, wobei LC_COLLATE die Sortierreihenfolge
> festlegt. Und die ist, wie wir wissen, für natürliche westliche
> Sprachen in der Regel a A b B, usw.
Hmmm, ja. Aber: Unix-Dateisysteme sind case-sensitiv. Nunja, aber ich sehe
Deinen Punkt.
Ich schreib ja auch "Merkwürdige Locale-Effekte" statt fehlerhaft oder so…
aber trotzdem findre ich das schon heftig.
> Aber gefährlich finde ich es trotzdem, weil man es von Unix sonst so
> gewohnt ist, dass Suchanfragen case-sensitiv sind.
Mal sehen, wie find das sieht:
root@merkaba /t/test# find -name "[A-Z]"
./C
./B
./A
root@merkaba /t/test# find -name "[a-z]"
./c
./b
./a
Also so oder so ist das in sich inkonsistent: bash macht es anders als find,
das ebenfalls aus dem GNU-Projekt ist, und anders als die Z-Shell.
> > Ich denke, das ist einen Bugreport wert!
>
> Tja, oder auch nicht. Ist nicht so einfach IMHO.
Naja, ja. Ich sehe schon, was Du meinst.
Ciao,
--
Martin
Reply to: