Seite 2: read mail really fast

Inhaltsverzeichnis

read mail really fast

Unix-Kommandos nehmen an, dass der Administrator weiß, was er vorhat. Zu lästigen Nachfragen, wie sie etwa in Form diverser Dialogboxen unter Windows auftauchen, lassen sich die Dateikommandos rm, mv oder cp auf Unix-Maschinen zwar bewegen (Parameter -i), aber letztlich mindern diese nur das Arbeitstempo oder stören den Skriptablauf. Eine gewisse Berühmtheit hat in diesem Zusammenhang der Löschbefehl rm erlangt, der ganze Verzeichnisbäume mit nur zwei Optionen (-rf) ins Nirwana schickt. Erfahrene Systemverwalter übersetzen das Kommando samt der beiden Parameter daher auch mit "read mail really fast" und warnen ausdrücklich vor dem unbedachten Aufruf von rm -rf /.

Deutlich eleganter erreicht man die gleiche Katastrophe, wenn man per Wildcard alle versteckten Dateien unter /root in einem Rutsch löschen will: Der Befehl rm -rf .* erledigt die Aufgabe zuverlässig, arbeitet sich im Dateibaum nach oben und schreddert das System, weil der Ausdruck .* dummerweise auch auf das übergeordnete Verzeichnis .. passt.

Ebenfalls auf der Verliererseite sind Admins, die sich den Kopf über Fehlermeldungen zerbrechen: Nach einem Tag voller Skripte, die Arbeiten auf Windows-Rechnern erledigen, soll der Unix-Server Daten per Skript einsammeln und wegsortieren: Nach den ganzen Batch-Skripten, deren Kommentare mit "rem" beginnen, erscheint dem müden Admin ein "rm" am Zeilenanfang durchaus als eine sinnvolle Kommentarmarkierung. Nach dem Start meldet das Programm zwar noch, dass es "cp" nicht finden könne, doch Quelle und Ziel landen unwiederbringlich im Orkus. Admins, die des Öfteren C programmieren, schweben dabei in noch größerer Gefahr. Verwechselt er das Shell-Kommentarzeichen # mit dem C-typischen //, sollte er schon einmal die Platten mit der neusten Datensicherung aus dem Schrank holen:

rm -rf /kannweg /kannauchweg // /sollnichtweg

Apropos Löschen in Shell-Skripten: Die Zeile rm -rf $DATAPATH/$DATADIR soll Daten unter $DATAPATH/$DATADIR entsorgen, doch tut sie das nur dann, wenn beide Variablen existieren und nicht leer sind. Ansonsten gilt auch hier "Read mail really fast".

In die Kategorie "shit happens" fallen vagabundierende Leerzeichen in den Pfadangaben eines Löschbefehls (statt rm -rf /tmp/ besser nicht rm -rf / tmp eintippen. Ärgerlich wird es jedoch bei Tastaturen die Sonderzeichen wie ~ erst nach einem weiteren Tastendruck in die Konsole schreiben und damit alle Dateien im Verzeichnis entsorgen. Auch die Reihenfolge der Kommandoparameter spielt bei rm eine nicht zu unterschätzende Rolle. Während der Admin älterer Unixe mit rm -i * die Löschung jeder Datei abnicken darf, nimmt das Kommando bei der Eingabe von rm * -i an, dass der letzte Parameter eine Datei ist.

Will man trotzdem Dateien rekursiv löschen, etwa weil der Server ausgedient hat, sollte man ihn sicherheitshalber vom LAN abstöpseln – vergessene Netzwerklaufwerke könnten sonst massiven Schaden nehmen.

RTFM ...

Der Befehl shutdown startet Unix-Rechner neu oder schaltet sie aus. Gäbe es dort nicht den Prozesstöter kill, könnte man auch shutdown als Killeranwendung bezeichnen.

Der Parameter -h gibt bei vielen Unix-Kommandos eine Kurzhilfe aus. Wer damit mal eben auf einem älteren Server die Optionen von shutdown nachschauen will ... fährt ihn herunter.

Unter Linux passiert das zwar nicht mehr so einfach, ein zweiter Parameter ist dafür notwendig. Das schützt den Admin jedoch nicht vor Fehlinterpretationen:

Kollege: "Wie fährt man denn einen Linux-Server runter?"
Admin: "Mit dem Kommando shutdown -h now"
... Klicker di klacker di klick ...
Kollege: "Dann fährt er auch wieder hoch, oder?"
Antwort: "Nein, das wäre dann shutdown -r now"
Kollege: "Mist! Dann muss ich jetzt doch die 80 Kilometer ins Rechenzentrum fahren!"

Solche Vorkommnisse müssen einem erfahrenen Administrator zu der niederschmetternden Erkenntnis gebraucht, die er einem Neuling mitteilte: "90 Prozent aller Fehler sitzen vor dem Monitor ..." Ein Zwischenruf vom anderen Ende des Büros: "... Mist ! ich habe den falschen Server heruntergefahren ...". Der erfahrene Kollege fährt wenig beeindruckt fort: "Ich korrigiere: 95 Prozent ..."