Subshell-Scoping in Bash: warum Variablen nach der Pipe verschwinden

1. Der klassische Bug: eine Zaehlvariable, die nach der Pipe wieder null ist

Kaum ein Bash-Verhalten sorgt bei Einsteigern fuer mehr Verwirrung als folgendes Muster: eine Variable wird vor einer Pipe auf null gesetzt, innerhalb eines while read-Loops nach der Pipe hochgezaehlt, und nach dem Loop zeigt echo trotzdem wieder den urspruenglichen Wert null an, obwohl der Loop sichtlich mehrfach durchlaufen wurde und jede Iteration die Variable sichtbar erhoeht haben sollte.

Das Verhalten ist kein Bug in Bash, sondern eine direkte Folge davon, wie Bash Pipes implementiert: jede Stufe einer Pipe, also jeder durch | getrennte Teil eines Befehls, laeuft standardmaessig in einem eigenen Kindprozess. Eine Variablenaenderung in einem Kindprozess kann den Elternprozess grundsaetzlich nicht erreichen, unabhaengig davon, wie die Pipe im Detail aufgebaut ist.

count=0
cat access.log | while read -r line; do
  count=$((count + 1))
done
echo "Zeilen gezaehlt: $count"
# Zeilen gezaehlt: 0   <- ueberraschend, obwohl der Loop lief

2. Warum jede Pipe-Stufe eine eigene Subshell ist

Bash startet fuer jeden Teil einer Pipe-Kette einen eigenen Prozess, damit alle Teile gleichzeitig laufen und Daten stroemartig durch den Kernel-Puffer der Pipe fliessen koennen, statt dass eine Stufe komplett fertig sein muss, bevor die naechste beginnt. Diese parallele Ausfuehrung ist der Grund, warum befehl1 | befehl2 ueberhaupt effizient funktioniert, hat aber die Nebenwirkung, dass jede Stufe ihre eigene Kopie des Environments erhaelt.

Beim while read-Loop im Beispiel bedeutet das konkret: cat access.log laeuft im ersten Kindprozess, der komplette while-Loop mit allen Zuweisungen an count laeuft im zweiten Kindprozess. Der zweite Kindprozess besitzt eine eigene Kopie von count, die er beliebig veraendern kann, aber diese Kopie stirbt mit dem Kindprozess, sobald die Pipe abgeschlossen ist, und die Elternshell sieht davon nichts.

3. Den Beweis fuehren: unterschiedliche Prozess-IDs auf beiden Seiten der Pipe

Wer diesem Mechanismus nicht traut, kann ihn direkt sichtbar machen, indem innerhalb und ausserhalb des Loops die aktuelle Prozess-ID mit $BASHPID ausgegeben wird. $BASHPID zeigt anders als $$ immer die tatsaechliche PID der aktuell ausgefuehrten Shell-Instanz, waehrend $$ stur die PID der urspruenglichen Login-Shell zeigt und Subshells damit verschleiert.

Der Vergleich zeigt sofort, dass die PID innerhalb des Loops eine andere ist als davor und danach, ein eindeutiger Beleg dafuer, dass tatsaechlich ein separater Prozess laeuft, dessen Speicher, einschliesslich aller darin gesetzten Variablen, beim Beenden vollstaendig verworfen wird und niemals mit dem Elternprozess geteilt war.

echo "Aussen: PID $BASHPID"
echo "a
b
c" | while read -r line; do
  echo "Innen:  PID $BASHPID, Zeile: $line"
done
echo "Aussen: PID $BASHPID"
# Aussen: PID 4821
# Innen:  PID 4823, Zeile: a
# Innen:  PID 4823, Zeile: b
# Innen:  PID 4823, Zeile: c
# Aussen: PID 4821   <- wieder die urspruengliche PID

4. shopt -s lastpipe: die letzte Pipe-Stufe im aktuellen Shell-Kontext ausfuehren

Bash bietet mit der Shell-Option lastpipe einen gezielten Ausweg: ist sie aktiviert, fuehrt Bash die letzte Stufe einer Pipe nicht in einer eigenen Subshell aus, sondern direkt im aktuellen Shell-Kontext. Im Beispiel von oben wuerde damit der while-Loop selbst, als letzte Stufe der Pipe, im selben Prozess wie die umgebende Shell laufen, und Variablenaenderungen darin blieben nach dem Loop erhalten.

Die Aktivierung erfolgt mit shopt -s lastpipe vor der betreffenden Pipe. Wichtig ist eine Einschraenkung: lastpipe wirkt nur, wenn Job Control fuer die Shell deaktiviert ist, was in nicht-interaktiven Skripten standardmaessig der Fall ist, in interaktiven Shell-Sitzungen jedoch meist nicht, sodass diese Option zuverlaessig vor allem in Skripten funktioniert, kaum aber direkt im Terminal.

#!/usr/bin/env bash
shopt -s lastpipe

count=0
cat access.log | while read -r line; do
  count=$((count + 1))
done
echo "Zeilen gezaehlt: $count"
# Zeilen gezaehlt: 128   <- korrekt, weil die letzte Stufe im Skript-Prozess laeuft

5. Die Grenzen von lastpipe: nur die letzte Stufe, nicht die ganze Kette

lastpipe loest ausschliesslich das Problem der letzten Stufe einer Pipe. Enthaelt die Kette mehr als zwei Glieder, etwa befehl1 | befehl2 | while read ..., laufen alle Stufen ausser der letzten weiterhin in eigenen Subshells, was fuer den typischen Anwendungsfall meist unproblematisch ist, weil die Zustandsaenderung ohnehin nur in der letzten Stufe gebraucht wird, aber bei komplexeren Ketten mit mehreren zustandsbehafteten Stufen nicht ausreicht.

Ausserdem gilt lastpipe nur fuer die Shell-Sitzung, in der es gesetzt wurde, es ist keine globale Einstellung und muss in jedem Skript, das darauf angewiesen ist, explizit erneut aktiviert werden. Wer ein Skript schreibt, das auch als eingebundene Funktion in einem interaktiven Terminal mit aktivierter Job Control laufen koennte, sollte sich nicht blind auf lastpipe verlassen, sondern eine der folgenden Alternativen in Betracht ziehen.

6. Process Substitution als Ausweg: keine Pipe, also keine zusaetzliche Subshell

Eine robustere und portablere Alternative ist, die Pipe komplett zu vermeiden und stattdessen mit Process Substitution (<(befehl)) zu arbeiten. Dabei wird die Ausgabe von befehl ueber einen speziellen Dateideskriptor bereitgestellt, den der while-Loop dann per gewoehnlicher Umleitung mit < liest, statt per | daran angebunden zu sein. Weil hier keine Pipe im eigentlichen Sinn existiert, muss Bash fuer den while-Loop selbst auch keine Subshell erzeugen, und er laeuft von vornherein im aktuellen Shell-Kontext.

Diese Loesung funktioniert unabhaengig davon, ob Job Control aktiv ist oder nicht, und damit sowohl in Skripten als auch interaktiv im Terminal zuverlaessig, was sie fuer Bibliotheksfunktionen, die in unterschiedlichen Kontexten aufgerufen werden koennten, oft zur saubereren Wahl macht als lastpipe.

count=0
while read -r line; do
  count=$((count + 1))
done < <(cat access.log)
echo "Zeilen gezaehlt: $count"
# Zeilen gezaehlt: 128   <- korrekt, ohne shopt noetig zu sein

7. Weitere Alternativen: direkte Umleitung und Variable-Capture vor der Schleife

Steht die Eingabe ohnehin als Datei zur Verfuegung, ist die einfachste Loesung, die Pipe ganz wegzulassen und die Datei direkt mit < an den while-Loop umzuleiten, ohne cat als Zwischenschritt zu bemuehen. Dieses Muster braucht weder lastpipe noch Process Substitution und funktioniert in jeder POSIX-kompatiblen Shell, auch in dash, wo weder lastpipe noch <(...) existieren.

Passt die Datenmenge komfortabel in den Speicher, ist eine weitere robuste Alternative, die Daten zuerst vollstaendig mit $(...) in eine Variable einzulesen und danach ganz ohne Pipe mit while read aus dieser Variable per Herestring zu verarbeiten, was ebenfalls keine zusaetzliche Subshell fuer die Schleife selbst erzeugt und zusaetzlich den Vorteil hat, in jeder Bash-Version ohne Sonderoptionen zu funktionieren.

# Direkte Umleitung statt cat | while
count=0
while read -r line; do
  count=$((count + 1))
done < access.log
echo "Zeilen gezaehlt: $count"

# Alternative: erst vollstaendig einlesen, dann per Herestring verarbeiten
content=$(cat access.log)
count=0
while read -r line; do
  count=$((count + 1))
done <<< "$content"

8. mapfile/readarray: das Problem durch Verzicht auf die Pipe-Schleife umgehen

Ein weiterer robuster Weg ist, gar keine Schleife hinter einer Pipe zu betreiben, sondern die komplette Ausgabe eines Befehls mit dem eingebauten mapfile (auch readarray genannt) direkt in ein Array einzulesen. mapfile selbst wird ueber Process Substitution oder direkte Umleitung gefuettert, laeuft also ebenfalls im aktuellen Shell-Kontext, und die anschliessende Verarbeitung der Array-Elemente per for-Schleife findet ohnehin schon in der Elternshell statt, ganz ohne read in einer Pipe.

Dieses Muster eignet sich besonders, wenn ohnehin auf jede Zeile mehrfach zugegriffen werden soll oder die Reihenfolge der Verarbeitung nicht zwingend mit der Reihenfolge des Einlesens uebereinstimmen muss, hat aber den Nachteil, dass die gesamte Ausgabe vorher vollstaendig im Speicher gehalten wird, was bei sehr grossen Dateien im Gegensatz zum stromweise arbeitenden while read mit Process Substitution ein limitierender Faktor sein kann.

mapfile -t lines < <(cat access.log)
count=0
for line in "${lines[@]}"; do
  count=$((count + 1))
done
echo "Zeilen gezaehlt: $count"
# Zeilen gezaehlt: 128   <- korrekt, mapfile und for laufen in der Elternshell

9. Pipe, lastpipe, Process Substitution und Datei-Umleitung im Vergleich

Welche Variante die richtige ist, haengt davon ab, ob eine Datei als Quelle vorliegt, ob Portabilitaet zu POSIX sh gebraucht wird und ob das Skript auch interaktiv mit aktivierter Job Control laufen koennte. Die folgende Tabelle stellt die vier Muster gegenueber.

10. Zusammenfassung

11. FAQ: Subshell-Scoping und Pipes: Das Wichtigste auf einen Blick