Hier wieder mal eine Geschichte aus dem Linux-Alltag. Gestern kam meine Frau zu mir und wollte unbedingt und kurzfristig ein kleines “KDE 4 -Problem” auf ihrem Opensuse 11.2-System gelöst bekommen.

Auftakt: Reihenfolge-Problem bei Bild-Dateien mit Gross- und Kleinbuchstaben unter Dolphin und Gwenview (KDE 4)

Mein Frau hatte diverse Bilder, die mit 2 verschiedenen Kameras und verschiedenen Chips gemacht worden waren, in einem Verzeichnis zusammengeführt. Im Nachhinein stellte sich dann heraus, dass es Dateibezeichnungen der Form “IMG_xxx.jpg” und der Form “img_xxx” gab. Insgesamt führte dies bei einer Betrachtung der Bilder über “dolphin” und “gwenview” unter KDE zu einer heillosen Verwirrung und “falschen” Reihenfolge der Bilder. Und das in der Gegenwart von Gästen, die natürlich alle Windows benutzen …

In meiner Naivität habe ich meiner lieben Frau in einem ersten Anlauf süffisant empfohlen, doch bitte unter Dolphin eine Sortierung nach dem Dateinamen durchzuführen und dann die großgeschriebenen Files, die alle an erster Stelle erscheinen würden, zu markieren und in einen separaten Ordner zu transportieren. Ganz so einfach gestaltete sich die Angelegenheit dann aber leider nicht – und die dann folgende Schelte hatte ich auch wirklich verdient.

Akt 1: Seltsame Sortierreihenfolge unter Dolphin und Konqueror

Was war das Problem? Der Punkt aus Sicht meiner Frau war der, dass bei der Sortierung in den genannten Programmen die Gross- und Kleinschreibung (scheinbar) nicht beachtet wurde. Dies führte im Fall der Bilder zu einer Vermischung von JPGs aus unterschiedlichen Aufnahme-Situationen. So führte eine Sortierung unter Dolphin nach dem Dateinamen zu einer Reihenfolge wie

img_010.jpg
IMG_010.jpg
IMG_011.jpg
img_012.jpg

wobei die “IMG_xxx” -Dateien eben zu einer anderen Aufnahme-Session gehörten als die “img_xxx”-Dateien.

Nun hatte meine bessere Hälfte natürlich selbst schon ein wenig eigene Recherche betrieben und auch alle ihr zugänglichen Einstellungsoptionen unter KDE durchgekämmt. Am Schluss beklagte sie sich dann vehement darüber, dass Dolphin, Konqueror und Gwenview unter KDE 4 zwar die Option zum Sortieren der angezeigten Dateien nach dem Dateinamen anböten, dass dabei aber eben die Groß/Klein-Schreibung vollständig ignoriert würde. Im Gegensatz zur Suche gäbe es auch keine Option, über die man die Beachtung der Groß/Kleinschreibung hätte aktivieren können. Noch schlimmer: Unter Dolphin reagierten auch Filterkriterien, die man in die zuschaltbare Filterleiste eingeben kann, nicht auf Unterschiede in der Groß/Klein-Schreibung.

Der normale User könne zudem auch unter den Systemeinstellungen keine Option finden, die einer Beachtung der Groß/Kleinschreibung bei Sortiervorgängen unter KDE geichkäme. Und nun wäre sie mit ihrem Latein am Ende und ich sei an der Reihe, was zu tun und zwar schnell – wegen der Gäste. Mein Vorschlag, die Bilder halt “händisch” umzusortieren, wurde mit ungläubigen Blicken und einem Hinweis auf die Anzahl der Bilder abgelehnt – und dann die obligatorische Frage nach dem Leistungsvermögen von Linux und dessen Administratoren, die ein zu diesem System überredet hätten ……

Intermezzo: Problembehebung über die Shell

Um das akute Problem zu beheben griff ich erstmal zu Hausmitteln: Terminalfenster, “cd” in das betroffene Verzeichnis, “mkdir gross” und “mkdir klein” abgesetzt und dann

find . -maxdepth 1 -name “img*” -exec cp -pv {} ./klein \;

sowie

find . -maxdepth 1 -name “IMG*” -exec cp -pv {} ./gross \;

und die Vorführung der Bilder war gerettet.

Akt 2: Ursachenforschung

Aber was war eigentlich mit Sortierung unter KDE los? War das Ganze überhaupt ein KDE-Problem?

Ich musste und muss zu meiner Schande gestehen, dass mir das von meiner Frau präsentierte Verhalten unter KDE
noch nie bewusst aufgefallen war. Ich konnte das erst auch nicht so recht glauben. (Im Kopf hatte ich natürlich die klassische ASCII-Reihenfolge und typische Wildcardgeschichten wie “[a-z]”, etc.)

Ich wurde jedoch eines Besseren belehrt, als ich folgenden Test mit “ls” und “sort” in einem Verzeichnis mit 4 Dateien “test_1.txt, test_2.txt, TEST_1.txt, TEST_2.txt” unternahm:

… > ls
test_1.txt TEST_1.txt test_2.txt TEST_2.txt

Das gleiche Ergebnis erschien auch mit

…> ls | sort
test_1.txt TEST_1.txt test_2.txt TEST_2.txt

– und das Durchprobieren diverser Optionen von “sort” änderte rein gar nichts. Das konnte doch nicht wahr sein ! Zur Sicherheit habe ich dann das Gleiche mal mit dem Root-Account ausprobiert – und siehe da, die Reihenfolge war nun wie erwartet:

… # ls
.directory TEST_1.odt TEST_2.odt test_1.odt test_2.odt

Nun wirklich misstrauisch geworden, sehe ich mir die “profile”-Einstellungen der Bash genauer an. Unter SUSE werden dabei Festlegungen unter “/etc/sysconfig” gezogen – interessant ist hier die Datei

/etc/sysconfig/language

mit dem Eintrag

RC_LANG=”de_DE.UTF-8″

Das Kommando “env | grep LANG” brachte denn unter einem normalen Useraccount auch konsistenterweise

LANG=de_DE.UTF-8

als Ergebnis. Hm, das wirkt ja eigentlich nicht so ungewöhnlich. Dann fällt einem ein, dass die LANG-Variable alle anderen “LC_….”-Variablen ersetzt also auch “LC_COLLATE”. Also Quercheck bei root:

… # env | grep LANG
LANG=POSIX

Aha – offenbar war das “Problem” an die Locale-Einstellungen gebunden. Ein Test mit “export LC_ALL=C” (C entspricht hier den Posix-Default-Einstellungen) bestätigte die Vermutung: Ab jetzt erschien auch unter dem normalen User-Acccount die gewünschte Reihenfolge.

…> export LC_ALL=C
…> echo $LC_ALL
C
…> ls | sort
TEST_1.odt TEST_2.odt test_1.odt test_2.odt

Was also war die Konsequenz? Die Sortier-Reihenfolge der “de_DE.UTF-8”- Collation entspricht nicht der gewohnten POSIX- bzw. ASCII-Reihenfolge, die man in jedem Linux-Anfängerkurs eingebläut bekommt.

de_DE.UTF-8 entspricht der Sortierung
“aAbB …. zZ”.

POSIX entspricht dagegen der Sortierung
“AB …Zab … z”

Akt 3: Nachdenken über potentielle Gefahren ?

Nun kam ich richtig ins Grübeln – was würde z.B. beim Löschen von Dateien und gleichzeitiger Verwendung der Wildcardsequenz [a-z] unter der Collation “de_DE.UTF-8” geschehen?

…> echo $LANG
de_DE.UTF-8
…> rm [a-z]*
…> ls

Tatsächlich ! Alle (!) Dateien – auch die mit großem Anfangsbuchstaben – waren gelöscht worden ! Oh, oh, … Das muss man sich wirklich merken !

Akt 4: Nachlesen unter den GNU-Definition zur Bash und LC_COLLATE

Unter folgender Quelle
http://www.gnu.org/software/bash/manual/bashref.html

liest man dementsprechend Folgendes:

“LC_COLLATE
This variable determines the collation order used when sorting the results of filename expansion, and determines the behavior of range expressions, equivalence classes, and collating sequences within filename expansion and pattern matching (see Filename Expansion). ”

Und bei “filename expansion” findet man:

“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.

For example, in the default C locale, ‘[a-dx-z]’ is equivalent to ‘[abcdxyz]’. Many locales sort characters in dictionary order, and in these locales ‘[a-dx-z]’ is typically not equivalent to ‘[abcdxyz]’; it might be equivalent to ‘[aBbCcDdxXyYz]’, for example. To obtain the traditional interpretation of ranges in bracket expressions, you can force the use of the C locale by setting the LC_COLLATE or LC_ALL environment variable to the value ‘C’. ”

Fazit und Nachspiel

Auf neueren Linux-Systemen (wie etwa SUSE 11.2) mit deutscher Lokalisierung wird für normale User meist eine “de_DE.UTF8”-Collation verwendet. Deshalb entspricht die Sortierung und die Abhandlung von Shell-Wildcards wie [a-z] nicht mehr den erwarteten Posix-Verhältnissen ! Das schlägt natürlich auch auf die KDE-Programme durch. (Das Gleiche gilt übrigens auch für Kollationen anderer Sprachbereiche).

Das sollte und muss man natürlich im Kopf behalten!

Die eigentliche potentielle Gefahr liegt aber im Einsatz von Wildcards der Form “[a-z]” bei Dateioperationen, da dadurch keineswegs – wie eigentlich erwartet – immer nur Kleinbuchstaben erfasst werden. Tja, eigentlich weiss man das ja …. theoretisch …. aber denkt man im Alltag wirklich immer drüber nach?

Wenn nicht, lohnt es sich jedenfalls, alte Shellscripts auf eventuelle Probleme, die durch den Einsatz von collation-abhängigen Wildcards verursacht werden könnten, durchzusehen.