Exit-Codes von find und xargs: das grobe 0/>0 von find gegenüber der Skala 123–127 von xargs

Worum es geht

Das Handbuch von find bleibt bewusst vage, sobald es um mehr als ein Ja/Nein geht: "find exits with status 0 if all files are processed successfully, greater than 0 if errors occur. This is deliberately a very broad description." (Status 0, wenn alle Dateien erfolgreich verarbeitet wurden, sonst grösser als 0 – ausdrücklich als sehr allgemeine Beschreibung gedacht.) Dazu kommt ein wirklich wichtiger Vorbehalt: Bei einem Exit-Status ungleich 0 gilt "you should not rely on the correctness of the results of find" (auf die Korrektheit der Ergebnisse ist kein Verlass) – einzelne Startpunkte oder noch ausstehende -exec ... {} +-Aufrufe wurden möglicherweise gar nie ausgeführt.

xargs gibt dagegen sehr genau an, wie der aufgerufene Befehl gescheitert ist:

Code	Bedeutung
0	Erfolg (und alle von xargs gestarteten Befehle endeten ebenfalls mit 0)
123	mindestens ein Aufruf des Befehls endete mit einem Status ausser 0 oder 255
124	der Befehl endete mit Status 255 (xargs liest danach keine weitere Eingabe mehr)
125	der Befehl wurde durch ein Signal beendet
126	der Befehl kann nicht ausgeführt werden (gefunden, aber nicht ausführbar)
127	der Befehl wurde nicht gefunden
1	ein anderer Fehler ist aufgetreten (in xargs selbst)

Das Handbuch nennt ausserdem ein technisches Detail, das für Skripte relevant ist: xargs startet Befehle direkt über execvp() und nicht über eine Shell. Deshalb gilt: "the shell's (128 + signal) convention for reporting that a process had been killed by a signal is not used by xargs" – 125 ist der eigene Code von xargs für diesen Fall, nicht 128+Signal.

Warum es wichtig ist

Das verbreitete Muster find . -name '*.log' | xargs rm vermischt das grobe „irgendwo ist etwas schiefgelaufen“ von find mit der genauen Skala von xargs. Ein Berechtigungsfehler in einem Unterverzeichnis führt dazu, dass find mit einem Status ungleich 0 endet (aber trotzdem alle Dateien an xargs weitergegeben hat, die es lesen konnte). Eine einzelne nicht zugängliche Zieldatei, die an rm übergeben wird, zeigt sich dagegen im Code 123 von xargs (gewöhnlicher Exit-Status ungleich 0) und überhaupt nicht im Code von find. Die beiden Fehler werden völlig unabhängig voneinander gemeldet, und eine Pipeline, die nur $? des letzten Befehls prüft, sieht nur die eine Hälfte des Gesamtbilds – den Teil, den xargs meldet.

So wird es angewendet

• Nach find | xargs beide Exit-Codes prüfen, sofern Shell bzw. Pipeline das erlauben (in bash pipefail zusammen mit PIPESTATUS); ein find ungleich 0 bei einem xargs mit 0 bedeutet, dass einige Dateien stillschweigend nie aufgelistet wurden.
• Einen Status ungleich 0 von find als „Ergebnisse möglicherweise unvollständig“ werten und nicht bloss als „ein Fehler wurde protokolliert“ – mit -print/-ls zur Diagnose oder mit enger gefassten Startpunkten erneut ausführen, um herauszufinden, was übersprungen wurde.
• Bei xargs 126/127 als Konfigurationsprobleme behandeln (falscher Name oder Pfad des Programms), 123/124/125 hingegen als Probleme einzelner Aufrufe eines an sich korrekten Befehls.
• find ... -print0 | xargs -0 ... verwenden, wenn Dateinamen Leerzeichen oder Zeilenumbrüche enthalten können – unabhängig von der Frage der Exit-Codes.

Stolpersteine

• Annehmen, der Exit-Code von find verrate, welche Datei oder welches Verzeichnis gescheitert ist – das tut er nicht; dafür muss stderr ausgewertet werden.
• Annehmen, der Code 125 von xargs folge der Shell-Nummerierung 128+Signal; laut Handbuch ist das ausdrücklich nicht der Fall.