grep, diff, cmp und test/[: Exit-Code 1 bedeutet «nicht gefunden», nicht «Fehler»

Worum es geht

Vier der am häufigsten von Agenten aufgerufenen Werkzeuge folgen einer gemeinsamen Konvention, die leicht falsch verstanden wird: Ein Exit-Code ungleich 0 bedeutet nicht immer, dass das Werkzeug fehlgeschlagen ist.

Werkzeug	0	1	2 (oder >1)
grep	eine Zeile wurde ausgewählt	keine Zeile wurde ausgewählt	ein Fehler ist aufgetreten
diff	Eingaben sind gleich	Eingaben unterscheiden sich	Problem (falscher Pfad, nicht lesbare Datei)
cmp	Dateien sind identisch	Dateien unterscheiden sich	Problem
test / [	Ausdruck ist wahr	Ausdruck ist falsch oder fehlt	ein Fehler ist aufgetreten

Das GNU-grep-Handbuch legt den Exit-Status so fest: "0 if a line is selected, 1 if no lines were selected, and 2 if an error occurred." Das diffutils-Handbuch sieht für diff und cmp dieselbe Dreiteilung vor: "0 if inputs are the same, 1 if different, 2 if trouble." POSIX definiert test/[ gleich: 0 für wahr, 1 für falsch (oder einen fehlenden Ausdruck) und jeden Wert über 1 für einen tatsächlichen Fehler.

Warum es wichtig ist

Bei allen vier Werkzeugen ist Exit-Code 1 bei einem grossen Teil der Aufrufe das erwartete Ergebnis: eine Suche ohne Treffer, zwei unterschiedliche Dateien, eine falsche Bedingung. Ein Agent, der «ungleich 0» mit «Befehl fehlgeschlagen» gleichsetzt, meldet ein normales negatives Ergebnis fälschlich als defekten Pipeline-Schritt. Schlimmer noch: Er bemerkt womöglich nicht, wenn der Code tatsächlich 2 (oder höher) lautet. Dann meldet das Werkzeug, dass es den Vergleich gar nicht durchführen konnte, etwa wegen falscher Mustersyntax, einer nicht lesbaren Datei oder eines Verzeichnisses anstelle einer Datei.

So wird es angewendet

• Auf den konkreten Wert verzweigen, nicht auf «null oder nicht null»: 1 als normale negative Antwort behandeln und die Fehlerbehandlung auf 2 (grep/diff/cmp) bzw. auf alle Werte über 1 (test) beschränken.
• Bei grep -q/--quiet die Einschränkung im Handbuch beachten: Wurde ein Treffer gefunden, wird weiterhin 0 gemeldet, selbst wenn beim Lesen einer anderen Datei ein unabhängiger Fehler auftrat. Der Exit-Code von -q allein belegt daher nicht, dass alle Eingaben lesbar waren.
• Bei diff/cmp in einer Pipeline, die bei einem echten Fehler deutlich scheitern, Unterschiede aber tolerieren soll, $? -gt 1 (oder -eq 2) prüfen statt $? -ne 0.
• Bei [ … ] in bash beachten, dass ein fehlerhafter Ausdruck ("unary operator expected", fehlendes ]) 2 zurückgibt, nicht 1. Variablen in Anführungszeichen zu setzen ("$var") verhindert die meisten dieser Fälle.

Stolpersteine

• Werden diese Werkzeuge mit einer Fehlerbehandlung im Stil von command || exit 1 umhüllt, geht die nützliche Unterscheidung zwischen «Nein» und «defekt» verloren.
• Es sollte nicht angenommen werden, dass andere Implementierungen (busybox grep, manche Neuimplementierungen von diff) genau 0/1/2 beibehalten. Die oben zitierten POSIX- und GNU-Texte beschreiben die übliche Grundlage, nicht jeden Klon.