Thema: shell
-
Exit-Codes von find und xargs: das grobe 0/>0 von find gegenüber der Skala 123–127 von xargs
find garantiert nur 0 bei vollständigem Erfolg und einen Wert grösser als 0 bei einem Fehler, bewusst ohne feinere Abstufung. xargs definiert dagegen eine genaue Skala dafür, wie der aufgerufene Befehl gescheitert ist: 123 für einen gewöhnlichen Exit-Status ungleich 0, 124 für Exit-Status 255, 125 für Abbruch durch ein Signal, 126 für nicht ausführbar und 127 für nicht gefunden. Wer find an xargs weiterleitet, muss in einer einzigen Pipeline zwei unterschiedliche Exit-Code-Konzepte prüfen.
-
zsh als Standard-Shell unter macOS: Was in einem für bash geschriebenen Skript nicht mehr funktioniert
macOS verwendet seit macOS 10.15 zsh als Standard-Login- und interaktive Shell. Ein Skript, das bashs Wortaufteilung, nullbasierte Arrays oder nachsichtiges Globbing voraussetzt, kann in der interaktiven zsh-Sitzung eines Agenten auf dem Mac anders oder gar nicht funktionieren – noch bevor das Alter von /bin/bash eine Rolle spielt.
-
grep, diff, cmp und test/[: Exit-Code 1 bedeutet «nicht gefunden», nicht «Fehler»
grep, diff, cmp und das Builtin test/[ verwenden dieselbe dreistufige Skala: 0 für ein positives Ergebnis, 1 für ein negatives Ergebnis ohne Fehler und 2 (bzw. >1) für echte Probleme. Der häufigste Fehler von Agenten im Umgang mit diesen Werkzeugen ist, 1 als Fehlschlag des Skripts zu deuten.
-
grep und ripgrep für die Codesuche: Rekursion, Filter und Exit-Codes
GNU grep durchsucht mit -r rekursiv, grenzt mit --include und --exclude-dir ein und liefert die Exit-Codes 0, 1 oder 2 für Treffer, keinen Treffer oder einen Fehler; ripgrep macht dasselbe standardmässig und überspringt dabei von Git ignorierte, versteckte und binäre Dateien. Vor dem Vertrauen in ein leeres Ergebnis wissen, was jedes Werkzeug überspringt.
-
Locale- und Datumsfallen in coreutils: LC_ALL, Zeichenbereiche und GNU- versus BSD-date
Die Locale ändert stillschweigend die Sortierreihenfolge, was [a-z] erfasst, Dezimaltrennzeichen und das Standard-Datumsformat; Skripte sollten LC_ALL=C (oder C.UTF-8) und TZ explizit setzen, explizite Datumsformate verlangen und GNU-spezifisches date -d oder BSD-spezifisches date -v meiden, solange die Plattform nicht bekannt ist.
-
sort, uniq und comm: Mengenoperationen auf Text, die sortierte Eingabe voraussetzen
uniq fasst nur benachbarte Duplikate zusammen, comm verlangt, dass beide Eingaben in derselben Kollationsreihenfolge sortiert sind, und die Reihenfolge von sort richtet sich nach LC_COLLATE; solche Pipelines unter LC_ALL=C ausführen, die richtigen Schlüsseloptionen wählen (-n, -h, -V, -k, -t) und comm -12 sowie comm -23 für Schnittmengen und Differenzen verwenden.
-
„exec format error“ und „cannot execute binary file“: Architektur- und Shebang-Konflikte
Der Kernel-Fehler ENOEXEC erscheint als „exec format error“ bzw. „cannot execute binary file: Exec format error“, wenn die CPU-Architektur nicht passt oder einem Skript eine brauchbare Shebang-Zeile fehlt. CRLF-Zeilenenden in der Shebang-Zeile führen zu einem verwandten Fehler („bad interpreter“ oder „required file not found“). Der Artikel zeigt, wie sich die Ursachen mit file(1) unterscheiden und gezielt beheben lassen.
-
find und xargs ohne Überraschungen: NUL-getrennte Namen, -exec + und Trockenläufe
Dateinamen können Leerzeichen und Zeilenumbrüche enthalten, deshalb sollten sie mit -print0 und xargs -0 (oder find -exec ... {} +) von find an andere Programme übergeben werden; die Auswahl vor dem Ergänzen von -delete mit -print testen und xargs -r verwenden, damit eine leere Liste nichts ausführt.
-
Mit jq auf der Kommandozeile mit JSON arbeiten
jq liest JSON, wendet einen Filter an und gibt das Ergebnis aus: -r für einfache Strings verwenden, -c für ein Objekt pro Zeile, --arg und --argjson, um Werte sicher zu übergeben, -e, um null oder false in einen Exit-Code umzuwandeln, sowie select, map und to_entries zum Umformen; Filter nie durch String-Verkettung zusammensetzen.
-
Shell-Skripte schreiben, die kontrolliert fehlschlagen
set -euo pipefail verwenden, jede Expansion in Anführungszeichen setzen, [[ ]] und Arrays bevorzugen, mit ShellCheck prüfen und das Parsen von ls vermeiden; ein Skript, das beim ersten Fehler stoppt, ist vertrauenswürdiger als eines, das weiterläuft.
-
Ein selbstprüfendes Ersttags-Setup-Skript: Bootstrap, Doctor, Smoke-Test
Ein Befehl nach dem Klonen erzeugt entweder eine funktionierende Umgebung oder eine präzise Liste dessen, was fehlt und wie es behoben wird: Ein nur lesendes Doctor-Skript prüft jede Voraussetzung, ein idempotentes Bootstrap installiert nur das, was die Prüfungen als fehlend melden, und ein Smoke-Test entscheidet über den Exit-Status; die CI führt es auf einer sauberen Maschine aus, damit es zwischen Neueinsteigenden nicht veraltet.
-
„Argument list too long“ (E2BIG) und das ARG_MAX-Limit
Expandiert ein Shell-Befehl zu zu vielen Argumenten, scheitert er mit „Argument list too long“, dem Fehler E2BIG von execve(2) beim Erreichen der Kernel-Obergrenze ARG_MAX. Der Artikel zeigt, wie sich das Limit messen lässt und wie sich ein fehlschlagendes Glob durch xargs oder das Batching von find mit -exec ... + ersetzen lässt, statt mit Quoting dagegen anzukämpfen.
-
sed und awk für zeilenorientierte Bearbeitungen: Ersetzen, Felder und Änderungen direkt in der Datei
sed wendet Bearbeitungsbefehle, vor allem s/regexp/replacement/, auf jede Zeile an; awk zerlegt Zeilen in Felder und führt Muster-Aktions-Paare aus. sed für Ersetzungen und Löschungen verwenden, awk für Spaltenarbeit und kleine Aggregationen, und -i, -n sowie die Unterschiede zwischen GNU und BSD bewusst handhaben.
Maschinenlesbar: JSON