Seite 9 - Bash

Ein Shell-Skript, das für tausend Dateien tausend externe Prozesse startet, ist kein Performance-Problem — es ist ein Design-Problem. Wer versteht, wie viel ein Fork kostet, welche Operationen Builtins abdecken und wie Caching in der Shell funktioniert, schreibt Skripte, die Sekunden statt Minuten benötigen.

Sequentielle Shell-Skripte lassen CPU-Kerne und Netzwerkbandbreite ungenutzt. xargs -P, GNU Parallel und manuelle Worker-Skripte ermöglichen echte Parallelisierung in der Shell — mit kontrollierbaren Job-Slots, zuverlässiger Fehlererkennung und Throttling-Mechanismen für ressourcensensible Umgebungen.

Gute interaktive Bash-Tools haben eine klare Bedienoberfläche: nummerierte Menüs mit select, Eingaben mit read -r und Timeout, farbige Statusmeldungen und Bestätigungsdialoge, die gefährliche Aktionen absichern – all das ist mit reinen Bash-Builtins umsetzbar.

Jede CI-Pipeline, die bei jedem Lauf Dependencies neu installiert oder Build-Artefakte komplett neu erzeugt, verschenkt Zeit und Geld. Ein Bash-Skript, das den Cache-Key konsequent aus einer Hashsumme relevanter Dateien bildet, sorgt dafür, dass ein Cache automatisch invalidiert wird, sobald sich etwas ändert, und ansonsten zuverlässig wiederverwendet wird.

Ein Shell-Skript, das auf dem Entwickler-MacBook problemlos läuft, scheitert im Alpine-basierten CI-Container — weil macOS Bash 3.2 ausliefert und Alpine nur Busybox-sh enthält. Das Verständnis der Grenze zwischen portabler POSIX-Shell und Bash-spezifischen Features ist Voraussetzung für Shell-Code, der im Team zuverlässig funktioniert.

Eine Umgebungsvariable, die in der Shell des Administrators funktioniert, aber im PHP-FPM-Prozess einer Magento-Anwendung schlicht fehlt, ist eines der häufigsten Rätsel im Serveralltag. Der Grund liegt fast immer im Scope: Umgebungsvariablen werden nur an Kindprozesse vererbt, niemals rückwärts oder quer zu unabhängigen Prozessbäumen, und systemweiter Scope funktioniert grundlegend anders als benutzerspezifischer Scope.

Ein nächtlicher mysqldump landet meist ungeprüft im Backup-Verzeichnis, bis er im Ernstfall gebraucht wird und sich als leer oder veraltet herausstellt. Eine automatisierte Datenbank-Dump-Analyse in Bash liest Größenverlauf, Tabellenzahlen und Schema-Änderungen direkt aus der Dump-Datei, ohne sie in eine Test-Datenbank einzuspielen.

String-Hacks in Bash – Dateilisten als Leerzeichen-getrennte Strings, Konfigurationswerte als kommaseparierte Felder – brechen systematisch, sobald Werte Sonderzeichen enthalten. Arrays in Bash sind die saubere Alternative: indexed Arrays für geordnete Listen, assoziative Arrays für Key-Value-Strukturen, Slices für Teilmengen und sichere Iteration für jeden Anwendungsfall.

Ein Cronjob, der nachts laeuft, verschwindet fuer Prometheus normalerweise spurlos: Kein laufender Prozess bedeutet keinen abfragbaren HTTP-Endpunkt. Der Node Exporter Textfile Collector loest dieses Problem, indem er einfache .prom-Dateien im Dateisystem einliest, die ein Bash-Skript selbst schreibt, und macht Cronjob-Dauer, Erfolg oder Fehlschlag damit ohne zusaetzlichen Dienst fuer Prometheus abfragbar.

Ein Deployment, das aus fuenf nacheinander aufgerufenen Bash-Skripten besteht, hinterlaesst ohne gemeinsame Kennung fuenf isolierte Log-Fragmente, die sich im Nachhinein kaum wieder zu einem zusammenhaengenden Ablauf zusammensetzen lassen. Eine Correlation-ID, einmal am Anfang erzeugt und konsequent per Umgebungsvariable an jedes aufgerufene Skript und jeden aufgerufenen Prozess weitergereicht, macht aus diesen Fragmenten einen durchsuchbaren, zusammenhaengenden Trace.