Schnell geschrieben sind Shellskripte oft eine Quelle mangelnder Robustheit, gefährlicher Sicherheitslücken oder bremsender Performance. Das muss nicht sein: Das Linux-Magazin demonstriert und erklärt die Stolperfallen. Diesmal: Wieso sich Schleifen und Leerzeichen nicht mögen.
Eigentlich hatten es die Entwickler von Sun gut gemeint und wollten nur helfen: In seinem großen Java-Werkzeugkasten liefert der Anbieter den Wrapper »HtmlConverter« mit, der Anwender unterstützen soll, die leidigen Pfade automatisch zu finden und Environment-Variablen zu setzen. Solche Aufgaben erledigen Shellskripte gerne und meist zuverlässig. Ist die Umgebung erkundet und sind die Variablen gesetzt, braucht der Wrapper nur noch das ursprüngliche Programm aufzurufen (siehe Listing 1).
|
Listing 1: Probleme beim |
|---|
01 $ ls -l
02 -rw-rw-r-- 1 pub lo 980 09-08-20 00:18 index.html
03 -rw-rw-r-- 1 pub lo 623 09-08-20 00:19 pub login.html
04 $ HtmlConverter -simulate index.html
05 Zu konvertierende Dateien:
06 /tmp/box/index.html
07 [...]
08 Konvertierung ok.
09 $ HtmlConverter -simulate "pub login.html"
10 Es sind keine zu verarbeitende Dateien vorhanden.
11 $ tail -2 /usr/bin/HtmlConverter
12 # Execute the converter
13 ${BINDIR}/java -jar ${LIBDIR}/htmlconverter.jar $*
|
Doch komisch: Analysiert das Programm, das eigentlich Applet-Code in HTML-Dateien konvertieren soll, die erste Datei »index.html« noch korrekt, so verweigert es beim zweiten Aufruf mit dem Dateinamen »pub login.html« seinen Dienst, wie Zeilen 9 und 10 anschaulich demonstrieren. Ein Blick auf die letzten Zeilen des Programmcode bestätigt: Einmal mehr kommt ein Shellskript nicht mit allen erlaubten Pfadnamen zurecht, offenkundig hat es Probleme mit Dateien, deren Namen Leerzeichen enthalten.
Umstrittene Umlaute
Im Prinzip sind als Dateiname unter den normalen Linux-Dateisystemen alle Zeichen außer dem Slash und dem Zeichen mit dem Wert 0 erlaubt, also durchaus auch Leerzeichen, Umlaute und ausländische Schriftzeichen, Dollarzeichen, Ampersands und führende Bindestriche. Ob das in jedem Fall nützlich ist, steht freilich auf einem anderen Blatt. Wer etwa per Skript alle Textdateien ausgeben möchte, greift oft auf ein Skript mit einer For-Schleife wie in Listing 2 zurück.
|
Listing 2: Einfache |
|---|
01 #!/bin/sh 02 for i in *.txt; do 03 echo $i ... 04 done |
Das klappt dann auch mit allen Sonderzeichen, wie Abbildung 1 zeigt. Einzig das Muster mit den drei führenden Punkten greift das Globbing-Muster »*.txt« nicht auf. Wer auch Punkt-Dateien aufnehmen möchte, muss daher das Muster ».*.txt« noch hinzufügen. Achtung: Das klappt nur mit einer Endung, denn auf ».*« passen auch die beiden Verzeichnisse ».« und »..«. Dotfiles mit mindestens zwei Buchstaben erwischt am besten das Shell-Pattern ».??*«.
Abbildung 1: Dateinamen erlauben auch Ungewohntes wie Blanks, führende Bindestriche oder ausländische Glyphen. Nicht alle Skripte gehen damit richtig um.
Skripte recyceln Daten
Wer genau hinschaut, stellt fest, dass in der Ausgabe die führenden Leerzeichen der Datei verschwunden sind, deren Name nur aus ebensolchen sowie der Endung besteht. Besser wäre beim Echo-Befehl alle Argumente in doppelte Anführungszeichen einzuschließen. Die werten nämlich Shell-Variablen noch aus, behalten aber alle Leerzeichen bei.
Nun lässt sich die Liste der Dateien nicht immer direkt durch so ein Muster, hier »*.txt« in Zeile 2, erzeugen, sondern ist das Ergebnis eines Befehls oder einer Verkettung von Befehlen. Da liegt es nahe, den Backquote-Operator »`Kommando`« der Bourne-Shell zu verwenden. Das lässt sich etwa in der Bash etwas lesbarer gestalten, wenn der Entwickler den Posix-Operator »$(Kommando)« verwendet. Sonst ist die Funktionsweise gleich.
Blanks verwirren Schleifen
Vorsicht ist allerdings geboten, wenn Entwickler das Ergebnis einer solchen Befehlssubstitution einer Variable zuweisen oder direkt in die Schleife einsetzen, wie dies in Listing 3 geschieht. Dass der Aufruf von »ls« in Zeile 2 das Extra-Argument »–« benötigt, liegt dabei nur indirekt an der Shell: Die Bash expandiert zuerst das Glob-Pattern und übergibt dessen Ergebnis als Parameter an den Unterprozess »ls«. Da aber einer der Namen mit einem Minuszeichen beginnt, fasst das Unix-Programm ihn als Option auf. Der doppelte Bindestrich signalisiert, dass nach ihm kein Parameter mehr als Option zu interpretieren ist.
