- Starship ist ein Open-Source-Projekt für eine Prompt mit geringem Gewicht, hoher Leistung und Flexibilität, die in verschiedenen Shell-Umgebungen verwendet werden kann
- Bietet breite Kompatibilität und unterstützt die meisten wichtigen Shells wie Bash, Zsh, Fish, Powershell und Tcsh
- Konfiguration und Anwendung sind möglich, indem für jede Shell einfach das jeweilige Initialisierungsskript hinzugefügt wird
- Geschrieben in Rust, was hohe Geschwindigkeit und Sicherheit gewährleistet; wird als einzelne Binärdatei bereitgestellt
- Bis ins kleinste Detail anpassbar
- Unterstützt eine gemeinsame Umgebung auf verschiedenen Plattformen wie Android, BSD, Linux, macOS und Windows und verbessert so Produktivität und Benutzerfreundlichkeit
Open-Source-Projekt Starship
- Starship ist ein Prompt-Tool, das Leistung und Anpassbarkeit zugleich bietet und auf verschiedenen Betriebssystemen und in unterschiedlichen Shells verwendet werden kann
- Im Vergleich zu herkömmlichen schweren Prompts zeichnet es sich durch schnelle Reaktionszeiten und geringen Ressourcenverbrauch aus; die hohe Anpassbarkeit hilft dabei, die Produktivität von Entwicklern zu steigern
Einrichtung in den einzelnen Shell-Umgebungen
- Bash:
- Am Ende der Datei
~/.bashrc den Code eval "$(starship init bash)" hinzufügen
- Fish:
- Am Ende der Datei
~/.config/fish/config.fish starship init fish | source hinzufügen
- Zsh:
- Am Ende der Datei
~/.zshrc den Code eval "$(starship init zsh)" hinzufügen
- Powershell:
- In
Microsoft.PowerShell_profile.ps1 Invoke-Expression (&starship init powershell) hinzufügen
- Der Speicherort der PowerShell-Profildatei kann über die Variable
$PROFILE geprüft werden
- Ion:
- In die Datei
~/.config/ion/initrc den Code eval $(starship init ion) eintragen
- Elvish:
- Nur Versionen ab v0.18 werden unterstützt
- In
~/.elvish/rc.elv den Code eval (starship init elvish) hinzufügen
- Tcsh:
- In
~/.tcshrc den Code eval \starship init tcsh`` eintragen
- Nushell:
- Nur ab v0.96 unterstützt; die Konfigurationsmethode könnte sich künftig ändern
- Der Pfad der Konfigurationsdatei lässt sich mit dem Befehl
$nu.config-path prüfen
- Auf diesen Pfad mit dem Code
starship init nu | save -f ... anwenden
- Xonsh:
- Am Ende der Datei
~/.xonshrc den Code execx($(starship init xonsh)) eintragen
- Cmd (Clink erforderlich):
- Clink v1.2.30 oder höher erforderlich
- Datei
starship.lua erstellen und im Clink-Skriptverzeichnis speichern
- Darin den Code
load(io.popen('starship init cmd'):read("*a"))() hinzufügen
2 Kommentare
Spannend, dass etwas auftaucht, das ich schon seit Jahren gern nutze :)
Ich verwende es noch seit der Zeit, als es als Zsh-Theme angeboten wurde ... hahaha
Hacker-News-Kommentare
Ich bin ein Nutzer, der maximalistische Prompts mag, und nutze beim Einrichten von Entwicklungsmaschinen oft Shell Bling Ubuntu über Starship.
Trotzdem ist dieser Stil nicht für alle geeignet.
Wenn man nur die dichteste Information hinzufügen möchte, empfehle ich, lediglich die Uhrzeit, zu der der Prompt erscheint, und die Laufzeit des letzten Befehls anzuzeigen.
Mit nur diesen beiden Informationen lässt sich leicht nachvollziehen, was wann passiert ist, und das bringt später große Vorteile beim Debugging oder bei der Protokollverwaltung.
Diese Vorgehensweise ist ein Tipp aus Michael W. Lucas’ Networking for System Administrators, ein Buch, das ich Entwicklern, die Netzwerkgrundlagen lernen wollen, ebenfalls oft empfehle.
Wenn man noch mehr Nerd-Punkte sammeln will, kann man die Zeit in Sekunden seit der UNIX epoch anzeigen.
Das hat den Vorteil, dass sich Zeitdifferenzen sehr leicht berechnen lassen.
Siehe das Shell Bling Ubuntu repo
In nushell werden solche Informationen standardmäßig bereitgestellt.
In der Ausführungshistorie (
history) kann man Details wie den Startzeitstempel des Befehls, die Laufzeit, das aktuelle Verzeichnis, den Exit-Status und mehr einsehen.Das ist sehr praktisch, weil nicht nur die Zeitdifferenz zwischen Befehlen, sondern auch die tatsächliche Laufzeit des Befehls selbst direkt angezeigt wird.
Ich habe meinen Prompt fast nie angepasst.
Wenn man emacs benutzt, sieht man die gewünschten Informationen ohnehin bereits im Editor.
Nur wenn ich es anderen zeigen muss, etwa beim Pair Programming, richte ich Starship ein und öffne dafür ein separates Terminal, sodass ich meine eigene Umgebung nicht zeigen muss.
Der Exit-Code des vorherigen Befehls ist aus ähnlichen Gründen wie oben ebenfalls sehr nützliche Information.
Es ist auch ziemlich hilfreich, die aktuelle Uhrzeit in einem menschenlesbaren Format anzuzeigen.
Und wenn der Exit-Status des vorherigen Befehls nicht 0 war, also bei einem Fehler, hilft es beim Debugging, das ebenfalls anzuzeigen.
Für mich reicht die Information über das aktuelle Verzeichnis allein völlig aus.
Es genügt, nur die Prompt-Farbe je nach Erfolg oder Misserfolg des letzten Befehls zu ändern.
Zusätzliche Informationen kann man bei Bedarf gesondert nachsehen.
Es weckt meine Neugier, wie die Altersverteilung der Starship-Nutzer wohl aussieht.
Mir persönlich ist das Interesse an Prompt-Anpassungen mit der Zeit stark verloren gegangen.
Ich bin zu dem Schluss gekommen, dass 90 % der Informationen, die selbst ein sehr ausgefeilter Prompt zeigt, während 90 % der Zeit unnötig sind.
Zu viele Informationen fühlen sich eher wie visuelles Rauschen an, sodass das Gehirn sie am Ende ignoriert und man sogar vergisst, dass sie überhaupt da sind.
Wirklich wichtige Informationen stoßen im Prompt ohnehin an Grenzen; zum Beispiel verrät ein Hinweis auf einen geänderten Git-Branch noch nicht, welche Dateien sich geändert haben, sodass man am Ende doch zusätzliche Befehle ausführen muss.
Ich habe über 20 Jahre Entwicklungserfahrung.
Git-Informationen im Prompt finde ich sehr nützlich.
Sie liefern zwar keine Details bis ins Letzte, erinnern mich aber daran, dass es nicht committete Änderungen oder vergessene Stashes gibt.
Starship fand ich interessant und habe es sofort installiert, aber Dinge wie die Anzeige von Tool-Versionen empfand ich als zu laut und habe es am Ende wieder deinstalliert.
Optionen wie Command-Timing oder Erfolgs-/Fehlerstatus fand ich gut, aber im Verhältnis zum Aufwand, eine komplexe Custom-Konfiguration zu pflegen, blieb zu wenig Nutzen übrig.
Aus Sicht eines Seniors mit mehr als 25 Jahren in der Branche nutze ich auffällige moderne Tools eher nicht.
Früher habe ich ein sehr einfaches PS1 verwendet, das nur Dinge wie Uhrzeit, meinen Account, den verbundenen Host und den aktuellen Pfad anzeigte, etwa so: <pre><code>export PS1="[\033[1;32m][\t \u@\h \w]\$[\033[0m]"</code></pre>
Andere ausgefeiltere Prompts habe ich mehrfach ausprobiert, sie haben aber kaum geholfen.
Inzwischen nutze ich Starship seit einigen Jahren sehr zufrieden.
Ich habe es so angepasst, dass nur die Informationen erscheinen, die ich brauche, und es ist dadurch sehr schnell und angenehm.
Einer der nützlichsten Teile meiner Prompt-Anpassung ist die Anzeige des Exit-Status des vorherigen Befehls.
Es gibt Fälle, in denen die Ausführung eines Befehls ohne jegliche Fehlermeldung scheitert, und dann ist ein Fehlhinweis ein starkes Signal.
Damit es im Alltag kein Rauschen erzeugt, zeige ich es allerdings nur bei Fehlern an.
Beispiel: <pre><code>» true » false (last command returned 1.)</code></pre>
Wenn ein Prozess durch ein Signal beendet wurde, wird das ebenfalls übersetzt angezeigt, etwa „last command exited on SIGSEGV“.
Umgekehrt ist es auch hilfreich, wenn ein Programm zwar Fehlermeldungen ausgibt, aber trotzdem mit einem Erfolgs-Code endet.
Als „very senior“-Nutzer mit jahrzehntelanger UNIX-Erfahrung bevorzuge ich den Starship minimal mode, weil er sauber ist.
Früher habe ich mich jahrelang mit diversen zsh-Setups herumgeschlagen, aber heute habe ich damit kaum noch hassle.
Falls jemand erwartet hat, dass Starship-Nutzer nur junge Leute sind, die in JavaScript mit Emojis um sich werfen: Es gibt auch Leute wie mich.
Allgemeiner betrachtet ist das ein Phänomen, das sich auf die gesamte Computing-Umgebung anwenden lässt.
Als ich jünger war, habe ich mein OS mit Gentoo selbst gebaut und mich obsessiv mit CPU-Optimierungs-Flags, Window-Managern, bashrc-Aliases und -Funktionen sowie dem Prompt-Setup beschäftigt.
Solche Optimierungsarbeiten sind als Teil des Lernprozesses durchaus hilfreich.
Mit der Holzbearbeitung verglichen: Als Anfänger verbringt man die meiste Zeit damit, Werkzeuge oder Kniffe zu bauen und zu verfeinern, doch irgendwann verlagert sich der Fokus auf die eigentliche praktische Arbeit.
Ich mag Linux immer noch, aber in einem vollen Alltag priorisiere ich „Arbeit“ statt Effizienz oder Perfektion und nutze deshalb einfach Debian und KDE als Standardumgebung.
Ich mag keinen unnötigen Zierrat oder Informationsüberfluss und bevorzuge daher eine minimale Terminal-Umgebung.
Starship zeigt aber bei Bedarf den passenden Kontext und lässt sich sehr fein anpassen.
Mein Standard-Prompt zeigt nur das aktuelle Verzeichnis, die Uhrzeit und ein
%.Wenn bestimmte Umgebungsvariablen (
KUBECONFIG,OS_CLOUDusw.) gesetzt sind, nimmt es die passenden Informationen ebenfalls auf.Sprachversionen wie Go oder Python werden je nach Nutzungskontext automatisch angezeigt.
Starship macht solche Setups wirklich einfach möglich und funktioniert ohne komplexe zsh-Plugin-Konfigurationen mit minimalem Overhead.
Besonders zusammen mit evalcache ist auch die Initialisierung sehr schnell.
Als Starship-Fan ein paar Kommentare:
Dass es sicher und schnell in Rust entwickelt wurde und als gebautes Binary vorliegt, sorgt dafür, dass die Performance deutlich besser ist als bei pythonbasiertem powerline, shellskriptbasiertem ohmybash, zshellbasiertem ohmyzsh oder spaceship.
Unterstützung für zsh, bash, sh und fish ist selbstverständlich, ebenso für MS Windows CMD und Powershell.
Dass man die Prompts auf allen Systemen mit einer einzigen Config-Datei verwalten kann, ist fast einzigartig.
Wenn es zu viele Informationen sind, kann man das leicht ändern, und auch Icons lassen sich deaktivieren.
Mit rund 100 Modulen gibt es praktisch keine Grenzen bei der Customization.
Ich verstehe nicht, warum Starship als „minimal“ vermarktet wird.
<pre><code>: ▶</code></pre>Tatsächlich hat es sehr viele Funktionen, und was man real im Einsatz sieht, sind riesige Prompts mit allen möglichen Verzierungen.
Ich nutze es ganz einfach so:
Wenn man wirklich minimal will, braucht man nicht unbedingt so ein Customization-Framework.
Gegenüber anderen Shells und Prompts hat Starships Konfigurationsdatei den Vorteil, dass sie selbst bei steigender Komplexität ziemlich intuitiv bleibt.
Man kann alle Funktionen deaktivieren.
<pre><code>format = """ $username\ $hostname\ $shlvl\ $directory\ $git_branch\ $git_commit\ $git_state\ $git_metrics\ $git_status\ $package\ $python\ $rust\ $env_var\ $custom\ $cmd_duration\ $jobs\ $time\ $status\ $shell\ $character"""</code></pre>Ich nutze gerade eine minimale Konfiguration in etwa dieser Art:
Letztlich kann man Starship minimal nutzen, aber seinem Wesen nach ist es eher ein maximalistischer Prompt, der möglichst viele Informationen und Inhalte aufnehmen kann.
Es wäre gut, das einfach anzuerkennen.
Ich benutze einen noch dünneren Pfeil als diesen.
<pre><code>PROMPT='%{%F{red}%}%~ %{%F{yellow}%}% › %{%F{reset_color}%}%'</code></pre>Sauber, schlicht und eine minimalistische Umsetzung.
Mich überrascht, wie oft Anpassbarkeit mit Maximalismus verwechselt wird.
Die Standardwerte sind etwas überladen, aber man kann es so weit reduzieren, wie man möchte.
Ich arbeite in mehreren AWS-Umgebungen und mit verschiedenen Runtimes, und die Kontextinformationen im Prompt helfen mir tatsächlich sehr.
Persönlich nutze ich schon lange die Kombination aus Starship + Nushell.
Ich mag, dass man es einmal installiert und danach nicht mehr anfassen muss.
Ich möchte direkt sehen, ob die Shell Node 20 oder 22 nutzt und ob Rust auf stable oder nightly steht.
Dass all das ohne zusätzliche Arbeit sofort angezeigt wird, finde ich sehr gut.
Unabhängig von Starship stört mich bei zsh-Prompts das Phänomen, dass beim Drücken von Enter der Cursor kurz an den Zeilenanfang springt und ein „Flash“ entsteht.
Bei ultra-fast Prompts ist es weniger stark, aber sobald der Prompt auch nur ein klein wenig etwas tut, ist dieses Verhalten sehr deutlich sichtbar.
Ich habe das in verschiedenen Terminals identisch beobachtet (
gnome-terminal,wezterm,kitty,alacritty,xterm).Nur im urxvt-Terminal tritt das Problem nicht auf.
Siehe Videoreproduktion.
Mich würde interessieren, worin die Ursache dieses Flash-Effekts liegt und wie man ihn vermeiden kann.
Wenn bei jedem Rendern des Prompts alle 100 ms nutzlose Informationen wie
git statusgeprüft werden, führt das zu einem unsichtbaren Produktivitätsverlust.Das Terminal sollte ein reaktionsschnelles Gedächtniswerkzeug sein, und man sollte vermeiden, dass es zu unnötigem Zierrat wird.
Es ist problematisch, wenn man sich um die Ausführungsgeschwindigkeit von Code kümmert, beim eigenen Tipplag aber nachsichtig wird.
Starship ist wirklich schnell.
Das Sammeln der nötigen Daten dauert nur wenige ms, und man kann leicht steuern, welche Informationen extrahiert werden.
Bei anderen Tools, die ich bisher genutzt habe, haben mich längere Verzögerungen immer gestört, aber bei Starship ist der Unterschied im Gefühl sehr deutlich.
Die 100 ms, die ein Mensch wahrnimmt, und die 100 ms in der CPU-Optimierung sind etwas völlig anderes.
Ich frage mich, was stärker optimiert werden sollte: dass der Prompt 100 ms braucht, um den Git-Branch oder Status anzuzeigen und damit den „flow“ unterbricht, oder dass ich selbst noch länger brauche, um den Befehl einzutippen.
Ein paar ms für sinnvolle Komfortfunktionen sind den Preis durchaus wert.
Letztlich geht es darum, ein Gleichgewicht zwischen Komfort und Minimalismus zu finden.
Sowohl extremer Minimalismus als auch übertriebene Verzierung können ineffizient werden.
Weil mich solche Verzögerungen störten, habe ich das kitty-Terminal gepatcht und den Starship-Prompt wie in vim oder emacs in eine untere status bar beziehungsweise modeline verlegt.
Die modeline wird asynchron aktualisiert, wodurch der Prompt selbst sehr schnell reagiert.
Der Nachteil ist, dass man kitty selbst patchen muss und ich das außerhalb meiner persönlichen Linux-Umgebung nicht testen konnte.
Siehe das zugehörige Patch-Projekt.
Ich frage mich, ob Prompt-Tools den Prompt-Bereich ähnlich wie ein TUI auch noch asynchron verändern könnten, nachdem die Prompt-Ausgabe bereits vollständig zurückgegeben wurde – etwa so, dass
kubectl,gitoderaws cli200 ms später zusätzliche Informationen einblenden.Dann könnte der Nutzer ohne Wartezeit sofort den nächsten Befehl eingeben, und Zusatzinformationen würden später ganz natürlich erscheinen.
Vielleicht ist es nicht die Optimierung der Codeausführung, sondern eher die zunehmende Zahl der verwendeten Layer, die es in der Praxis schwieriger macht, die Eingabelatenz des Prompts zu optimieren.
Als ich die offizielle Website besucht habe, hatte ich das Gefühl, dass dort keine klare Erklärung dafür gegeben wird, warum man Starship verwenden sollte.
<pre><code>- Ergebnis des letzten Befehls (Farben: grün, rot, violett)Mein aktuelles Prompt-Setup zeigt auf einen Blick die folgenden Informationen:
Wenn der letzte Befehl erfolgreich war, wird er grün angezeigt, bei Fehlern rot und bei Abbruch violett.
Ich könnte zur Zielgruppe gehören, aber auf der Homepage wird für mich nicht klar vermittelt, „warum“ ich es benutzen sollte und welche Verbesserungen es konkret bringt.