Prozess-Substitution

Was Process Substitution ist

Process Substitution ist eine Bash- und Zsh-Erweiterung, die einen Befehl in einen Pfad zu einer named pipe (FIFO) oder einem /dev/fd/N-Eintrag verwandelt. Der äußere Befehl bekommt damit einen Dateinamen in die Hand, hinter dem aber kein File auf der Platte sitzt, sondern ein laufender Prozess.

Ein einfaches Beispiel: <(echo Hallo) ergibt einen Pfad wie /dev/fd/63. Ein cat darauf liest die Ausgabe von echo:

cat <(echo "Hallo aus dem FIFO")
echo <(echo "test")

Hallo aus dem FIFO
/dev/fd/63

Wichtig: Process Substitution ist kein POSIX. In dash, ash oder klassischem sh schlägt sie fehl oder wird als „Hintergrund-Prozess plus Klammer-Subshell” missverstanden. Skripte mit #!/bin/sh müssen darauf verzichten — wer es nutzen will, schreibt #!/usr/bin/env bash oder #!/bin/bash.

Syntax <(cmd) — Befehls-Output als Datei

Die Lese-Variante <(cmd) ist mit Abstand am häufigsten. Sie löst ein konkretes Problem: Ein Tool erwartet Dateinamen als Argumente — du hast aber nur die Live-Ausgabe eines anderen Befehls. Der klassische Fall ist diff, das per Definition zwei Dateien vergleicht.

diff <(ls /etc) <(ls /etc.bak)

3a4
> legacy.conf

Ohne Process Substitution müsstest du ls /etc > a.txt; ls /etc.bak > b.txt; diff a.txt b.txt; rm a.txt b.txt schreiben — vier Schritte und zwei Wegwerf-Dateien. Mit <(...) wird daraus eine einzige Zeile, und der Kernel räumt die FIFOs nach Programm-Ende selbst auf.

Der Trick ist, dass <(cmd) syntaktisch ein Wort ist — also überall stehen kann, wo der äußere Befehl einen Dateipfad erwartet. wc -l <(seq 1 100), md5sum <(curl -s https://example.org/), comm -12 <(sort a) <(sort b): Alles funktioniert, solange das Tool seine Eingabe sequenziell liest.

Syntax >(cmd) — Eingabe für einen Befehl

Die Schreib-Variante >(cmd) ist das Spiegelbild: Was in den Pseudo-Pfad geschrieben wird, landet auf der stdin von cmd. Damit kannst du eine einzige Datenquelle gleichzeitig an mehrere Verbraucher schicken — ohne Zwischendatei, in einem einzigen Pipeline-Aufruf.

./build.sh 2>&1 | tee >(grep ERROR > errors.log) >(grep WARN > warns.log) > build.log

tee schreibt seine Eingabe normalerweise auf stdout und in beliebig viele Dateien. Mit Process Substitution sind die „Dateien” hier in Wahrheit zwei laufende grep-Prozesse — der Build-Output landet also gleichzeitig in build.log (über den regulären >-Operator), in errors.log (gefiltert auf ERROR) und in warns.log (gefiltert auf WARN). Drei Empfänger, ein Durchlauf.

Ein anderer Klassiker ist >(cmd) als Ziel für Tools, die eine Output-Datei verlangen, du aber direkt weiterverarbeiten willst — etwa tar mit -f:

tar -czf >(ssh backup-host "cat > backup.tar.gz") /var/www

tar denkt, es schreibt in eine Datei — tatsächlich landet der gepackte Stream direkt im SSH-Tunnel zum Backup-Host. Spart eine ganze Reihe Zwischenschritte und vermeidet Speicherbedarf für ein temporäres Archiv.

Wann Process Substitution sinnvoll ist

Die Frage „warum nicht einfach Pipe?” stellt sich oft. Die Antwort: Pipes sind single-input — ein Befehl bekommt einen Stream auf stdin, fertig. Sobald du zwei oder mehr Streams gleichzeitig vergleichen, mischen oder verteilen willst, oder ein Befehl partout einen Dateinamen statt stdin will, kommst du mit klassischer Pipe nicht weiter.

Es gibt also drei klare Use-Cases: Mehrere Inputs, Datei-erwartender Befehl und while-Schleifen ohne Subshell-Verlust. Für alles andere ist die einfache Pipe weiterhin das richtige Werkzeug.

Vergleich mit Pipe

Pipe und Process Substitution sehen oberflächlich ähnlich aus, sind aber strukturell unterschiedlich. Die Pipe ist einkanalig und unidirektional: a | b verbindet as stdout mit bs stdin. Process Substitution ist mehrkanalig und kann beidseitig verlaufen — du kannst beliebig viele <(...)- und >(...)-Pseudo-Pfade gleichzeitig in einem Befehl haben.

paste <(seq 1 5) <(seq 11 15) <(seq 21 25)

Mit klassischen Pipes wäre dieses Pattern nicht direkt machbar — paste braucht drei Datei-Argumente, und Pipes liefern nur einen Stream. Process Substitution lässt jeden seq-Aufruf parallel laufen und übergibt paste drei lesbare Pfade.

Ein zweiter Unterschied betrifft den Exit-Code: Bei einer Pipe steht der finale Exit-Code der Pipeline klassisch nur für den letzten Befehl, mit pipefail für den ersten gescheiterten. Bei Process Substitution ist der Exit-Code des äußeren Befehls ausschlaggebend — das Ergebnis von cmd in <(cmd) geht standardmäßig verloren, was zu schwer auffindbaren Bugs führen kann.

Praxis-Patterns

Die folgenden Muster sind die typischen Anwendungsfälle, in denen Process Substitution den entscheidenden Unterschied macht.

Diff von zwei Befehlen ist der Klassiker schlechthin. Du willst zwei Verzeichnisse, zwei Konfigurationen oder zwei Versionen eines Befehls vergleichen — ohne Tempdateien.

dpkg -l > /tmp/vor.txt
sudo apt upgrade -y
diff <(sort /tmp/vor.txt) <(dpkg -l | sort)

Dasselbe Prinzip funktioniert für sortierte Logs, JSON-Outputs (mit jq-Pipeline) oder Konfigurations-Dumps von zwei Servern (diff <(ssh a "cat /etc/foo") <(ssh b "cat /etc/foo")).

File-Comparison ohne Temp-File geht über diff hinaus: Auch comm, cmp und sdiff arbeiten mit zwei Datei-Argumenten. Damit lassen sich Schnittmengen, Differenzen und Vereinigungsmengen direkt über Pipelines bilden.

comm -12 <(sort -u liste1.txt) <(sort -u liste2.txt)

comm -12 zeigt die Zeilen, die in beiden sortierten Eingaben vorkommen — die Schnittmenge. Ohne Process Substitution müsstest du beide Listen in Tempdateien sortieren, was den Code spürbar aufbläht.

Tee an mehrere Filter spart einen Durchlauf, wenn du denselben Stream auf mehrere Arten verarbeiten willst. Logfiles in mehrere Filter-Buckets aufzuteilen ist der Standard-Anwendungsfall:

make 2>&1 \
  | tee build.log \
  | tee >(grep -i error > errors.log) \
        >(grep -i warning > warnings.log) \
  > /dev/null

Der Build läuft genau einmal; die Ausgabe wird parallel in drei Dateien sortiert. Ein zweiter, klassischer Durchlauf wäre nicht nur ineffizient, sondern bei nicht-deterministischen Builds (Timestamps, parallele Tasks) auch nicht reproduzierbar.

While-Loop ohne Subshell-Trap ist der vielleicht wichtigste Pattern überhaupt. Wer eine while read-Schleife mit Pipe befüllt, läuft in die Subshell-Falle: Variablen, die in der Schleife gesetzt werden, sind außerhalb verloren.

zaehler=0
while read -r datei; do
    zaehler=$((zaehler + 1))
done < <(find . -type f -name "*.log")
echo "Gefunden: $zaehler Logfiles"

Gefunden: 17 Logfiles

Die Konstruktion done < <(cmd) umleitet stdin der Schleife auf den Output von cmd — und weil das keine Pipe ist, läuft die Schleife in der aktuellen Shell. zaehler bleibt nach dem Loop erhalten. Mit find ... | while read; do ...; done wäre zaehler außen weiterhin 0.

Paste von Befehls-Outputs kombiniert mehrere parallele Streams spaltenweise:

paste <(cut -d' ' -f1 /etc/hosts) \
      <(uptime | awk '{print $(NF-2)}')

Beide Befehle laufen parallel; paste legt ihre Ausgaben in zwei Spalten nebeneinander. Ohne Process Substitution wäre derselbe Effekt nur mit Tempdateien oder einer komplizierten awk-Lösung machbar.

Weiterführende Ressourcen

Externe Quellen

• Bash-Manpage: Process Substitution (man7.org) — Offizielle Referenz zu <(...) und >(...)
• GNU Bash-Handbuch: Process Substitution — Beispiele und Hinweise zur Implementierung
• Bash Pitfalls (mywiki.wooledge.org) — Häufige Fehler rund um Subshells und Pipes
• Greg’s Wiki: ProcessSubstitution — Tiefer Einblick mit weiterführenden Mustern

Verwandte Artikel

• Streams und Pipes — stdin, stdout, stderr und ihre Umleitung
• Heredocs — Mehrzeilige Strings als stdin und der Herestring <<<
• Schleifen — while, for und until im Skript
• Funktionen — Wiederverwendbare Code-Bausteine
• Skript-Grundlagen — Shebang, Permissions und der robuste Header