Die Entwickler der Shell fish haben Version 4.2.0 veröffentlicht. Zu den wichtigsten Neuerungen zählen mehrzeilige Befehle in der verlaufsbasierten Autovervollständigung sowie grundlegende Änderungen bei der Zeichenkodierung.

Die Autovervollständigung auf Basis der Befehlshistorie schlägt nun auch mehrzeilige Kommandos vor – eine Funktion, die bei komplexeren Shell-Skripten oder verschachtelten Befehlen für viele Nutzer im Alltag praktisch ist. Zudem wurden Probleme beim Löschen mehrzeiliger transienter Prompts behoben: Wenn ein solcher Prompt mehr Zeilen umfasst als der finale Prompt, wird er jetzt korrekt entfernt.

Ein weiteres praktisches Feature betrifft die Terminal-Konfiguration: Anwender können jetzt den Titel des Terminal-Tabs getrennt vom Fenstertitel setzen, indem sie die Funktion fish_tab_title definieren – gut für den Überblick. Bei sehr langen Kommandozeilen blendet fish außerdem den Teil des mehrzeiligen Prompts aus, der aufgrund der Bildlaufposition nicht mehr sichtbar ist. Das verhindert doppelte Zeilen nach dem Neuzeichnen.

UTF-8 jetzt vorausgesetzt

Eine grundlegende Änderung betrifft die Zeichenkodierung: fish geht jetzt immer von UTF-8 aus, selbst wenn das System kein UTF-8-Locale konfiguriert hat. Eingabebytes, die kein gültiges UTF-8 darstellen, werden weiterhin korrekt verarbeitet – Dateipfade mit veralteten Kodierungen lassen sich also nach wie vor verwenden, werden aber möglicherweise anders auf der Kommandozeile dargestellt. Auf Systemen ohne Multi-Byte-Locale verzichtet fish künftig auf ASCII-Ersatzzeichen für Unicode-Symbole wie das Auslassungszeichen.

Die Mausbedienung wurde flexibler: fish deaktiviert nicht mehr zwangsweise die Mauserfassung (DECSET/DECRST 1000), sodass Nutzer per Mausklick den Cursor bewegen oder Vervollständigungsvorschläge auswählen können. Die Tastenkombination alt-p fügt zudem kein überflüssiges Leerzeichen mehr zur Kommandozeile hinzu.

Standalone-Build nun Standard

Für Distributoren und Entwickler ist relevant, dass der Standalone-Build-Modus jetzt standardmäßig aktiv ist. Die Dateien in $CMAKE_INSTALL_PREFIX/share/fish werden künftig nicht mehr verwendet – mit Ausnahme der HTML-Dokumentation. Dadurch brechen künftige Updates laufende Shells nicht mehr ab, wenn sich interne Hilfsfunktionen geändert haben. Die Datendateien werden vorerst redundant installiert, um bereits laufende Shells zu schützen. Die minimale unterstützte Rust-Version wurde auf 1.85 geändert.

Release-Tags und Quellcode-Archive sind nun wieder GPG-signiert. Die Dokumentation in den Release-Paketen wird jetzt mit der aktuellen Sphinx-Version erstellt, wodurch die vorgenerierten Man-Pages OSC-8-Hyperlinks enthalten. Die Sphinx-Abhängigkeit ist jetzt in pyproject.toml spezifiziert, wodurch Nutzer uv für den Dokumentations-Build einsetzen können.

Plattform-spezifische Verbesserungen

Unter macOS setzt fish als Login-Shell die Variable MANPATH nun korrekt, wenn diese bereits in der Umgebung vorhanden war. Ein Windows-spezifisches Problem, bei dem die webbasierte Konfiguration nicht startete, wurde ebenfalls behoben. Für MSYS2 gibt es einen Workaround für Konsole und WezTerm, der verhindert, dass diese das falsche Arbeitsverzeichnis beim Öffnen neuer Tabs verwenden.

Im Rahmen der Version 4.0, die im Februar 2025 erschien, hatten die fish-Entwickler den Kerncode von C++ nach Rust portiert. Release 4.2.0 behebt mehrere Regressionen aus den Vorgängerversionen 4.0.0 und 4.1.0, darunter Probleme mit der webbasierten Konfiguration unter Python 3.9, falsche Terminal-Modi bei bestimmten Kommandos und Fehler beim Speichern universeller Variablen unter MSYS2. Auch VTE-basierte Terminals zeigen beim Ändern der Fenstergröße wieder das korrekte Verhalten.

Schließlich wurden auch die Übersetzungen erweitert: Neben den bereits vorhandenen Sprachen ist nun Chinesisch (Taiwan) mit an Bord, zudem wurden die französischen Übersetzungen ergänzt. Die Release Notes auf GitHub listen alle Änderungen detailliert auf. Für Linux stehen Standalone-Binaries für verschiedene CPU-Architekturen bereit, macOS-Pakete können über Homebrew bezogen werden. Windows-10- und -11-Nutzer müssen das Windows Subsystem for Linux (WSL) heranziehen, darüber hinaus lässt sich fish mit Cygwin und MSYS2 verwenden.

(fo)

Bei Richard Seidl ist in dieser Episode Sam Goetjes zu Gast. Die beiden sprechen über Vertrauen, Vorurteile und Fairness in algorithmischen Entscheidungen. Ausgangspunkt ist Goetjes‘ Masterarbeit: Ein Bewerbungsszenario mit menschlichen und maschinellen Empfehlungen und gezielt gesetztem Gender-Bias. Die Studie zeigt, wie sich das Vertrauen über die Zeit verschiebt und der Algorithmus oft schneller Vertrauen erhält.

Für Tests heißt das: nicht nur Modelle messen, sondern Bias-Risiken beobachten, Datenquellen offenlegen und Pilotphasen sauber designen. Agil gedacht heißt es, Feedback-Schleifen ernst zu nehmen und Entscheidungen überprüfbar zu machen.

Bei diesem Podcast dreht sich alles um Softwarequalität: Ob Testautomatisierung, Qualität in agilen Projekten, Testdaten oder Testteams – Richard Seidl und seine Gäste schauen sich Dinge an, die mehr Qualität in die Softwareentwicklung bringen.

Die aktuelle Ausgabe ist auch auf Richard Seidls Blog verfügbar: „Mensch vs. Maschine: Wer urteilt fairer? – Sam Goetjes“ und steht auf YouTube bereit.

(mai)

Es könnte so schön sein: Als neues Teammitglied wendet man sich einem Softwareprojekt zu, alle wissen, was sie zu tun haben, die Anforderungen sind klar und verständlich und das Team beherrscht die Technik (und nicht umgekehrt). Gibt es doch mal Probleme, dann kümmern sich eigens dafür vorgesehene Rollen darum, und räumen die Schwierigkeiten beiseite. Die Organisation sorgt dafür, dass alle in Ruhe arbeiten können. Am Ende hat man dann eine Sache ganz gewiss erreicht: Anwender beziehungsweise Kunden erhalten ein Produkt mit echtem Mehrwert. Das klingt doch zu schön, um wahr zu sein!

Aber ist es nicht häufig so, dass man als neues Teammitglied in ein Softwareprojekt hineingerät, und eben nicht alle wissen, was sie zu tun haben, und die Anforderungen ebenso wie die Technik unbeherrschbar sind? Mit den Problemen steht man häufig alleine da, Kunden und Anwenderinnen erhalten schließlich kein Produkt mit Mehrwert, und Projektziele erreicht das Team nur unzureichend.

Dazu gibt es tatsächlich Statistiken wie der Standish Group Chaos Report aus dem Jahre 2020. Die Teilnehmenden der zugrunde liegenden Umfragen waren überwiegend IT-Führungskräfte von Dienstleistern aus verschiedenen Branchen wie Banken, Versicherungen, Fertigung, Einzelhandel, Gesundheitswesen sowie aus öffentlichen Einrichtungen auf lokaler, staatlicher und föderaler Ebene. Dabei bezieht sich der Report auf den globalen Markt.

Die Zahlen besagen, dass 31 Prozent aller Softwareprojekte erfolgreich verlaufen, das heißt, die Projekte bleiben innerhalb der Zeitplanung, innerhalb des Budgets und liefern am Ende den besagten Mehrwert für die Anwender beziehungsweise Kunden. Aber was ist mit den restlichen 69 Prozent? Die Hälfte der Projekte haben zumindest enorme Probleme verschiedenster Art (u. a. wird das Budget überschritten), und 19 Prozent scheitern vollständig, das heißt sie kommen nicht zu einem befriedigenden Ende, und verursachen ausschließlich Kosten.

Im Fokus dieses Artikels stehen eben diese Projekte, die zu den 50 Prozent gehören, die Projekte, die (noch) nicht vollständig gescheitert sind, aber auch noch nicht auf gutem Kurs – also Sanierungsfälle, die man wieder in die richtige Richtung drehen kann. Und richtige Richtung bedeutet: Am Ende wird den Kunden tatsächlich ein Produkt mit Mehrwert geliefert.

Welche Faktoren führen zu Problemen?

Es gibt sehr viele Faktoren, die (nicht nur) in Softwareprojekten zu Problemen führen können. In Sanierungsfällen stößt man häufig unter anderem auf folgende Herausforderungen:

• Unklare Anforderungen: Der Kunde ist nicht in der Lage, das, was er haben will, klar zu artikulieren, wodurch Anforderungen widersprüchlich oder unbrauchbar sind. Immer neue Sonderfälle führen zum gefürchteten Scope Creep: Die schleichende Ausweitung des Projektumfangs, wobei häufig weder Zeit noch Budget oder Ressourcen entsprechend angepasst werden.
• Unrealistische Deadlines: Den Kunden werden Lieferzeitpunkte von Features versprochen, ohne vorher mit dem Entwicklungsteam gesprochen zu haben. Das Team kann jedoch nicht rechtzeitig liefern, weil es zu viel zu tun gibt. Dadurch entsteht Unzufriedenheit, und auf Dauer leidet die Qualität der Software, da das Team nebenbei immer neue Brandherde löschen muss.
• Strukturlose Agilität: Es wird viel von agilen Methoden oder agilen Transformationen gesprochen, aber die Umsetzung erfolgt oft nur halbherzig. Prioritäten ändern sich täglich, weil man „agil arbeitet“, und aus dem gleichen Grund existiert auch keine langfristige Planung. Stakeholder beginnen, sich in Meetings und kurzfristigen Planungen einzumischen, da sie das Gefühl haben, die Kontrolle zu verlieren.
• Unkontrolliert eskalierende technische Schulden: Aus Zeitgründen wird schnell etwas implementiert, und „wir verbessern das später“ ist das Mantra innerhalb des Projekts. Die Zahl von Workarounds und Quickfixes steigt, und irgendwann verbringen Entwicklerinnen und Entwickler mehr Zeit damit, über den Code und das Projekt zu fluchen, als neue Features zu implementieren. Davor haben sie ohnehin Angst, denn jede Codeänderung kann unvorhersehbare Konsequenzen mit sich bringen.
• Politik und Machtkämpfe: Es gibt viele Projektbeteiligte, die etwas zu sagen haben, was dazu führt, dass es häufig lange dauert, bis Entscheidungen getroffen werden, da niemand für vermeintlich falsche Entscheidungen verantwortlich sein möchte. Es gibt aus dem Management unterschiedliche, teilweise sich widersprechende Anforderungen, und Features werden aus politischen Gründen entwickelt oder blockiert.

Diese Liste lässt sich beliebig fortsetzen und soll nur einen kleinen Eindruck vermitteln, welche Problematiken häufig anzutreffen sind. Oftmals ist es jedoch so, dass sich diese Probleme zunächst verstecken und neuen Mitarbeitenden erst nach einiger Zeit im Projekt auffallen.

Echte Probleme aus echten Projekten

Wie sieht die Praxis aus? Zur Veranschaulichung dienen zwei beispielhafte Sanierungsfälle. Sie zeigen, wie dort eingesetzte Kollegen aus dem Unternehmen des Autors mit den dort vorherrschenden Problemen umgegangen sind.

Ein Disclaimer vorab: Ähnlichkeiten mit „lebenden oder toten Projekten“ sind rein zufällig – niemand sollte sich in einem der Projekte wiedererkennen können, Inhalte und Branchen sind verschleiert, einige Stellen sind überzeichnet, andere vereinfacht. Die zugrundeliegenden Probleme entsprechen jedoch der Realität.

Kaufen, kaufen, kaufen – E-Commerce

Das erste Beispiel führt in den E-Commerce-Sektor. Inhaltlich geht es um das Thema Identitätsmanagement. Grundsätzlich soll die SSO-(Single Sign-on)-Funktionalität von Keycloak, einer Open-Source-Software für Identitäts- und Zugriffsmanagement (Identity and Access Management, IAM) um weitere Services angereichert werden. Als besonderer Bonus: Das Projekt soll annähernd auf der sogenannten grünen Wiese starten – für den Kollegen, der als Lead-Developer fungiert und dem ein neues Team versprochen wird, scheinbar ein Glücksgriff. Bei diesem Sanierungsfall lagen die Probleme allerdings kurz nach Start in das Projekt bereits klar auf der Hand:

Beim versprochenen Entwicklerteam handelte es sich um drei Mitarbeitende, die zwar aus IT-affinen Umfeldern kamen, jedoch nicht über eine klassische Entwicklerausbildung verfügten. Tatsächlich handelte es sich mehr oder weniger um Hobbyprogrammierer, die nie zuvor mit Java Software entwickelt haben, und Java war als Sprache gesetzt.

Diese drei hatten bereits angefangen, etwas zu implementieren, es war jedoch unbrauchbar – sowohl vom Design als auch von der konkreten Codequalität her. Darüber hinaus erwiesen sich die Anforderungen als vollkommen unklar. Unterschiedliche fachliche Ansprechpartner lieferten verschiedene Aussagen, die sich häufig sogar widersprachen. Detailwissen über Prozesse und Use Cases existierte nicht.

Im Projekt gab es niemanden, der die wenigen vorliegenden Anforderungen entgegennahm, um sie für die Entwicklung aufzubereiten und zu priorisieren – in agilen Projekten wäre das etwa ein Product Owner.

So konnte das Entwicklungsteam zunächst nur auf Basis der wenigen bekannten Anforderungen arbeiten, und wenn man den fachlichen Ansprechpartnern den aktuellen Stand zeigte, führte das häufig dazu, dass das Entwicklungsteam wieder zurück in den Code musste, weil (vorher unbekannte) Sonderfälle nicht berücksichtigt wurden.

Zu guter Letzt gab es kein Vorgehensmodell sowie kein wirkliches Projektmanagement. Es gab lediglich das Entwicklungsteam mit einem Lead-Developer und einige am Projekt beteiligte Mitarbeitende, die gelegentlich Aussagen über die Anforderungen machten. Unabhängig davon gab es natürlich ein Management, das Ergebnisse sehen wollte, aber nicht verstehen konnte, warum das Entwicklungsteam nicht vernünftig arbeitet.