bash shell if then else

Es war drei Uhr morgens, als das Telefon klingelte. Ein Junior-Admin hatte ein Bereinigungsskript gestartet, das alte Log-Dateien löschen sollte. Das Problem? Eine einzige fehlende Variable in einer Bash Shell If Then Else Abfrage führte dazu, dass die Bedingung fälschlicherweise als wahr interpretiert wurde, während der Pfad-String leer blieb. Anstatt /var/log/app/old/ zu leeren, fing das Skript an, das Wurzelverzeichnis zu löschen. Dieser Fehler kostete das Unternehmen knapp 40.000 Euro an Wiederherstellungskosten und acht Stunden Stillstand der Kundenplattform. Ich habe solche Szenarien in den letzten fünfzehn Jahren oft erlebt. Meistens liegt es nicht an mangelnder Intelligenz, sondern an der Annahme, dass Bash sich wie eine moderne Programmiersprache verhält. Das tut sie nicht. Sie ist ein Werkzeug aus den 70ern, das gnadenlos jeden Tippfehler in eine Katastrophe verwandelt.

Der fatale Glaube an die logische Wahrheit in Bash Shell If Then Else

Der größte Fehler, den ich sehe, ist die Annahme, dass ein leerer String oder eine nicht gesetzte Variable in einer Bash Shell If Then Else Struktur automatisch zu "falsch" evaluiert wird. In Sprachen wie Python oder JavaScript mag das oft so sein, aber Bash ist hier tückisch. Wenn Sie if [ $VARIABLE == "true" ] schreiben und $VARIABLE ist leer, sieht die Shell am Ende nur if [ == "true" ]. Das ist ein Syntaxfehler, der das Skript entweder abbricht oder – noch schlimmer – bei bestimmten Flags einfach weiterläuft und unvorhersehbare Zweige ausführt. Erfahren Sie mehr zu einem ähnlichen Thema: diesen verwandten Artikel.

Ich habe Projekte scheitern sehen, weil Entwickler dachten, sie könnten sich auf die implizite Logik verlassen. In der Praxis müssen Sie Variablen immer in Anführungszeichen setzen. Immer. Wer das ignoriert, spielt russisches Roulette mit seinen Daten. Ein Profi schreibt if [[ "$VARIABLE" == "true" ]]. Die doppelten Klammern sind kein Luxus, sondern eine Lebensversicherung, da sie Wortsplitting und Probleme mit leeren Zeichenketten wesentlich sicherer handhaben als die alten einfachen Klammern.

Die Arroganz der einfachen Test-Klammern

Viele verlassen sich auf die alten [ ] Tests, weil sie es in einem Blogpost von 2005 gelesen haben. Das ist ein technischer Rückschritt, der Sie Zeit kostet. Die einfachen eckigen Klammern sind eigentlich ein Alias für das Programm test. Das bedeutet, jedes Mal, wenn das Skript diesen Punkt erreicht, muss ein Prozess-ähnliches Verhalten simuliert werden. Das ist langsam und fehleranfällig bei Sonderzeichen. Golem.de hat dieses faszinierende Gebiet ebenfalls behandelt.

Warum [[ ]] fast immer die bessere Wahl ist

In meiner Zeit als Systemarchitekt habe ich Skripte optimiert, die durch den exzessiven Einsatz von alten Test-Strukturen unnötig instabil waren. Die erweiterten Klammern [[ ]] erlauben reguläre Ausdrücke und verlangen keine Maskierung von Größer-als- oder Kleiner-als-Zeichen. Wer heute noch if [ $A -gt $B ] schreibt, wenn er if (( A > B )) für Zahlen oder [[ $A > $B ]] für Strings nutzen könnte, der baut sich mutwillig Stolperfallen ein. Es geht hier nicht um Ästhetik. Es geht darum, dass Sonderzeichen wie * oder & innerhalb von alten Klammern vom System interpretiert werden können, was zu Fehlern führt, die man in der Testumgebung kaum findet, die aber in der Produktion bei einer Datei mit Leerzeichen im Namen zuschlagen.

Missachtung von Exit-Codes und die falsche Sicherheit

Ein weiterer Punkt, an dem viel Geld verbrannt wird: Man prüft den Erfolg eines Befehls nicht direkt im Kontrollfluss. Viele Anfänger führen einen Befehl aus, hoffen, dass er klappt, und prüfen dann im nächsten Schritt irgendetwas anderes. Das ist Wahnsinn.

Stellen Sie sich vor, Sie sichern eine Datenbank. Der falsche Ansatz sieht so aus: Sie rufen den Backup-Befehl auf. Danach prüfen Sie mit einer Bash Shell If Then Else Konstruktion, ob die Datei im Backup-Ordner existiert. Klingt logisch? Ist es nicht. Was ist, wenn die Datei existiert, aber nur 0 Bytes groß ist, weil die Festplatte voll war? Der Befehl ist fehlgeschlagen, aber Ihre Prüfung sagt "Datei ist da, alles super".

Der richtige Weg ist, den Exit-Status des Befehls direkt zu nutzen. Jeder Befehl in Linux gibt einen Wert zurück. 0 bedeutet Erfolg, alles andere ist ein Fehler. Anstatt um drei Ecken zu prüfen, ob eine Datei da ist, fragen Sie direkt den Erfolg des Kopiervorgangs ab. Das spart Zeilen, reduziert die Komplexität und verhindert, dass Sie nachts wegen korrupter Backups aufwachen.

Vorher und Nachher: Ein reales Beispiel aus der Automatisierung

Schauen wir uns an, wie ein instabiler Prozess in einer deutschen Hosting-Umgebung aussah und wie wir ihn repariert haben.

Der schlechte Ansatz: Ein Skript sollte prüfen, ob ein Verzeichnis existiert, dorthin wechseln und Dateien löschen. Der Entwickler schrieb eine Prüfung, die nur testete, ob der Name des Verzeichnisses nicht leer war. Danach kam der Befehl zum Wechseln des Verzeichnisses und dann der Löschbefehl. Das Problem war, dass das Verzeichnis zwar einen Namen hatte, aber wegen eines Netzwerkfehlers (NFS-Mount verloren) nicht erreichbar war. Der cd-Befehl schlug fehl, das Skript blieb im aktuellen Verzeichnis (dem Home-Verzeichnis des Skript-Users) und löschte dort alles. Das Ergebnis war ein gelöschtes User-Profil und zwei Stunden Arbeit für die Wiederherstellung aus dem Snapshot.

Der richtige Ansatz: Wir haben das Skript umgebaut. Zuerst wurde die Variable strikt validiert. Dann wurde der Wechsel in das Verzeichnis direkt in die Bedingung eingebaut. Wenn der Wechsel nicht zu 100 % erfolgreich war (Exit-Code 0), wurde der then-Teil mit dem Löschbefehl gar nicht erst betreten. Stattdessen sprang das Skript sofort in den else-Zweig, schrieb eine Fehlermeldung in das zentrale Logging-System und beendete sich sicher. So wurde verhindert, dass Befehle im falschen Kontext ausgeführt wurden. Dieser kleine Unterschied in der Logik verhinderte in den folgenden Monaten mindestens drei weitere Vorfälle bei instabilen Netzwerkverbindungen.

Die Falle der verschachtelten Bedingungen

Ich sehe oft Skripte, die aussehen wie ein baufälliger Turm aus Holzklötzen. Fünf Ebenen von Einrückungen, in denen man sich fragt, welcher else-Zweig eigentlich zu welchem if gehört. Das ist nicht nur schwer zu lesen, es ist unmöglich zu warten. Wenn Sie nach sechs Monaten einen Fehler suchen müssen, weil die Skalierung Ihrer Cloud-Instanzen nicht funktioniert, werden Sie diese Komplexität hassen.

In der professionellen Praxis nutzen wir "Guard Clauses". Das bedeutet: Man prüft zuerst die Fehlerfälle und bricht das Skript frühzeitig ab. Wenn die Variable nicht gesetzt ist: Exit. Wenn das Verzeichnis nicht schreibbar ist: Exit. Wenn der API-Key fehlt: Exit. Erst wenn alle Ampeln auf Grün stehen, kommt der eigentliche Hauptteil des Codes. Das hält den Code flach und übersichtlich. Ein Skript, das flach strukturiert ist, lässt sich viel einfacher durch automatisierte Tests jagen als ein Monstrum mit zwanzig verschachtelten Verzweigungen.

Mathematische Vergleiche sind keine String-Vergleiche

Ein Fehler, der regelmäßig zu falschem Verhalten führt, ist die Verwendung von Operatoren für den falschen Datentyp. In Bash ist alles erst einmal ein String. Wenn Sie Zahlen vergleichen wollen, nutzen Sie oft -eq, -ne, -lt oder -gt. Wenn Sie aber Zeichenketten vergleichen, nutzen Sie == oder !=.

Ich habe erlebt, wie ein Monitoring-Skript Alarm schlug, weil es dachte, dass "10" kleiner als "2" ist. Warum? Weil der Entwickler [[ "10" < "2" ]] geschrieben hatte. Für die Shell ist das ein alphabetischer Vergleich. Und alphabetisch kommt die "1" vor der "2", also ist "10" tatsächlich "kleiner". Das Skript war für ein System gedacht, das die Last überwacht. Bei einer Last von 10 passierte nichts, weil das Skript dachte, alles sei im grünen Bereich. Erst bei einer Last von 2 wurde gewarnt. Das hat die Server fast zum Schmelzen gebracht. Verwenden Sie für Zahlen immer die doppelt runden Klammern (( 10 > 2 )). Das ist intuitiv und mathematisch korrekt.

Der Realitätscheck

Bash-Programmierung ist kein Handwerk für Ästheten. Es ist ein Handwerk für Paranoide. Wenn Sie glauben, dass Ihr Skript funktioniert, weil es auf Ihrem Laptop einmal durchgelaufen ist, liegen Sie falsch. Es wird in der echten Welt scheitern, sobald ein Dateiname ein Leerzeichen hat, ein Server kurzzeitig nicht erreichbar ist oder eine Umgebungsvariable fehlt.

Um mit dieser Technologie erfolgreich zu sein, müssen Sie aufhören, Bash wie eine "richtige" Programmiersprache zu behandeln. Sie ist ein Kleber. Und Kleber hält nur dann, wenn die Oberflächen sauber sind. Das bedeutet:

• Validieren Sie jeden Input.
• Nutzen Sie moderne Strukturen wie [[ ]] und (( )).
• Gehen Sie immer vom Scheitern jedes einzelnen Befehls aus.

Wer diese Disziplin nicht aufbringt, wird immer wieder Zeit mit der Suche nach Fehlern verschwenden, die eigentlich vermeidbar wären. Es gibt keine Abkürzung zur stabilen Automatisierung. Es braucht Erfahrung, die Bereitschaft, aus den Fehlern anderer zu lernen, und die ständige Skepsis gegenüber dem eigenen Code. Ein gutes Skript ist nicht eines, das bei Erfolg glänzt, sondern eines, das beim kleinsten Anzeichen von Problemen sicher anhält, bevor es Schaden anrichtet. Das ist die ungeschminkte Wahrheit über die Arbeit in der Administration. Es ist oft mühsam, aber es ist der einzige Weg, um nachts ruhig schlafen zu können.