starship/starship

☄🌌️ The minimal, blazing-fast, and infinitely customizable prompt for any shell!

Website · Installation · Configuration

                       

The minimal, blazing-fast, and infinitely customizable prompt for any shell!

• Fast: it's fast – really really fast! 🚀
• Customizable: configure every aspect of your prompt.
• Universal: works on any shell, on any operating system.
• Intelligent: shows relevant information at a glance.
• Feature rich: support for all your favorite tools.
• Easy: quick to install – start using it in minutes.

Explore the Starship docs  ▶

🚀 Installation

Prerequisites

• A Nerd Font installed and enabled in your terminal (for example, try the FiraCode Nerd Font).

Step 1. Install Starship

Select your operating system from the list below to view installation instructions:

Android

Install Starship using any of the following package managers:

Repository	Instructions
Termux	pkg install starship

BSD

Install Starship using any of the following package managers:

Distribution	Repository	Instructions
Any	crates.io	cargo install starship --locked
FreeBSD	FreshPorts	pkg install starship
NetBSD	pkgsrc	pkgin install starship

Linux

Install the latest version for your system:

curl -sS https://starship.rs/install.sh | sh

Alternatively, install Starship using any of the following package managers:

Distribution	Repository	Instructions
Any	crates.io	cargo install starship --locked
Any	conda-forge	conda install -c conda-forge starship
Any	Linuxbrew	brew install starship
Alpine Linux 3.13+	Alpine Linux Packages	apk add starship
Arch Linux	Arch Linux Extra	pacman -S starship
CentOS 7+	Copr	dnf copr enable atim/starship dnf install starship
Gentoo	Gentoo Packages	emerge app-shells/starship
Manjaro		pacman -S starship
NixOS	nixpkgs	nix-env -iA nixpkgs.starship
openSUSE	OSS	zypper in starship
Void Linux	Void Linux Packages	xbps-install -S starship

macOS

Install the latest version for your system:

curl -sS https://starship.rs/install.sh | sh

Alternatively, install Starship using any of the following package managers:

Repository	Instructions
crates.io	cargo install starship --locked
conda-forge	conda install -c conda-forge starship
Homebrew	brew install starship
MacPorts	port install starship

Windows

Install the latest version for your system with the MSI-installers from the releases section.

Install Starship using any of the following package managers:

Repository	Instructions
crates.io	cargo install starship --locked
Chocolatey	choco install starship
conda-forge	conda install -c conda-forge starship
Scoop	scoop install starship
winget	winget install --id Starship.Starship

Step 2. Set up your shell to use Starship

Configure your shell to initialize starship. Select yours from the list below:

Bash

Add the following to the end of ~/.bashrc:

eval "$(starship init bash)"

Cmd

You need to use Clink (v1.2.30+) with Cmd. Create a file at this path %LocalAppData%\clink\starship.lua with the following contents:

load(io.popen('starship init cmd'):read("*a"))()

Elvish

Add the following to the end of ~/.elvish/rc.elv:

eval (starship init elvish)

Note: Only Elvish v0.18+ is supported

Fish

Add the following to the end of ~/.config/fish/config.fish:

starship init fish | source

Ion

Add the following to the end of ~/.config/ion/initrc:

eval $(starship init ion)

Nushell

Add the following to the end of your Nushell env file (find it by running $nu.env-path in Nushell):

mkdir ~/.cache/starship
starship init nu | save -f ~/.cache/starship/init.nu

And add the following to the end of your Nushell configuration (find it by running $nu.config-path):

use ~/.cache/starship/init.nu

Note: Only Nushell v0.78+ is supported

PowerShell

Add the following to the end of your PowerShell configuration (find it by running $PROFILE):

Invoke-Expression (&starship init powershell)

Tcsh

Add the following to the end of ~/.tcshrc:

eval `starship init tcsh`

Xonsh

Add the following to the end of ~/.xonshrc:

execx($(starship init xonsh))

Zsh

Add the following to the end of ~/.zshrc:

eval "$(starship init zsh)"

Step 3. Configure Starship

Start a new shell instance, and you should see your beautiful new shell prompt. If you're happy with the defaults, enjoy!

If you're looking to further customize Starship:

• Configuration – learn how to configure Starship to tweak your prompt to your liking

• Presets – get inspired by the pre-built configuration of others

🤝 Contributing

We are always looking for contributors of all skill levels! If you're looking to ease your way into the project, try out a good first issue.

If you are fluent in a non-English language, we greatly appreciate any help keeping our docs translated and up-to-date in other languages. If you would like to help, translations can be contributed on the Starship Crowdin.

If you are interested in helping contribute to starship, please take a look at our Contributing Guide. Also, feel free to drop into our Discord server and say hi. 👋

💭 Inspired By

Please check out these previous works that helped inspire the creation of starship. 🙏

• denysdovhan/spaceship-prompt – A ZSH prompt for astronauts.

• denysdovhan/robbyrussell-node – Cross-shell robbyrussell theme written in JavaScript.

• reujab/silver – A cross-shell customizable powerline-like prompt with icons.

❤️ Sponsors

Support this project by becoming a sponsor. Your name or logo will show up here with a link to your website.

📝 License

Copyright © 2019-present, Starship Contributors.
This project is ISC licensed.

starship's Issues

Starship Discord

As was suggested by @Snuggle, I think we should use a synchronous communication platform for discussions that would be noisy to have on GitHub. Since we're starting with a new stack, this could be a good way to ramp up on Rust and share learning resources. 😄

I considered a few platforms including Spectrum, Gitter, Slack, and Discord, and ultimately decided that Discord would make the most sense for the time being.

Here were the pros and cons considered for each service

Spectrum

Pros

• GitHub login
• Searchable

Cons

• No mobile/desktop app
• Not very widely used
• Threaded posts serve the same purpose as GitHub Issues

Gitter

Pros

• GitHub login
• Mobile/desktop apps
• Searchable
• GitHub integration

Cons

• Lack of polish
• Mobile/desktop apps have limited functionality

Slack

Pros

• Mature mobile/desktop apps
• Searchable
• Integrations
• Conversation threading
• Widely used

Cons

• 10k message limit
• File storage limit
• Limited integrations

Discord

Pros

• Mature mobile/desktop apps
• Searchable
• Integrations
• Voice chat (could come in handy for pairing?)
• Widely used
• Unlimited messages

Cons

• Gamer-centric

I'm open to switching to another platform if we see a good reason to.

Here's the invite link: https://discord.gg/8Jzqu3T

Starship: The next-generation shell prompt for astronauts

🔔 @denysdovhan, @salmanulfarzy, @maximbaz, @Snuggle, @sirMerr

Howdy Spaceship/Spacefish crew! 👋

Inspired by the work @denysdovhan did on denysdovhan/robbyrussell-node and this discussion back in November, I went ahead and started work on starship two weeks ago displeased with the amount of duplicated effort that is made to maintain both spaceship and spacefish.

I'd like to discuss the possibility of consolidating our efforts, forming a Starship organization, and all working on one unified codebase that could become the next-generation shell prompt for astronauts across shells. 😄

I totally understand if there's any hesitance, a lot of amazing work has been put into creating the other projects, and this is a totally different beast in a new language for most of us (I didn't know a drop of Rust two months ago 😅). But, this also presents a new opportunity to start from scratch, and rethink our approach with regards to performance, safety, testing, and compatibility.

What has been made so far is purely a proof of concept, which I have no problems scrapping if we want to collectively rethink the architecture of the project.

I will personally keep working on this, putting spacefish into maintenance mode, but I would love to hear from you all about proposed next steps.

🚀

Create CONTRIBUTING.md for the project

Create a CONTRIBUTING.md file in the repo detailing how to get the local development environment up and running, a breakdown of the project structure, and tips for first-time contributors to the repo.

Here are some good examples from other repos:

• https://github.com/opengovernment/opengovernment/blob/4dc9499f735b680c124f04100b1ab19146242a13/CONTRIBUTING.md
• https://github.com/rails/rails/blob/81b8edc31dd11ae2bbff52bdd1fa730c024405d8/CONTRIBUTING.md
• https://github.com/prettier/prettier/blob/ed15b6d04e60a75d81c406ee899a86690187d44e/CONTRIBUTING.md

Add custom prompt character

This would be a handy feature to have (and this feature has already been implemented in Spacefish)

RFC: Rethinking the approach to sections/segments

Motivation

Thinking over the implementation of spaceship, the "section" architecture has made sense for a long time, but as the complexity of sections grew with feature requests, I think we should rethink the approach to how sections of the prompt are divided.

The kubectl sections is a good example of where the "section" has been outgrown:

[kubectl prefix] [kubectl symbol] [kubectl context] ([kubectl namespace])
      at                ☸️               aks1            kube-system

This model only allows for prefix, value, and suffix. The only way to compose the above section is by giving individual components to a section multiple jobs, which will make configuration more difficult down the line.

Design

What I have in mind is the following breakdown:

Prompt
└── Module
    ├── Prefix
    ├── Suffix
    └── Segment
        └── Value

Prompt - The whole visible prompt

Module - A collection of segments. In the above example, kubectl would be the module, with a prefix of at . The module could contain the default styling for each segment within it. A module could have one or many segments.

Segment - A segment is an individually configurable component within a module. In the above example, kubectl namespace would be a segment, which would inherit the styling from its module, but could have its styling overwritten through configuration or could be disabled altogether.

Drawbacks

• Clarity when it comes to documenting the project structure to future contributors
• Overhead involved with creating simpler modules (e.g. char)

Questions

• Would we want prefixes/suffixes for segments as well as for modules?

Taking a look at kubectl namespace in the above example, would the parentheses around the namespace be simply a part of the segment value? It would be a shame to not support configurability with regard to the parentheses being there, but maybe that level of configuration is too granular? 🤔

I have done very little OOP, so I am very open to suggestions to feedback!

Add event logging to starship

Feature Request

Implement logging for use when debugging and investigating issue reports. 🚩

Describe the solution you'd like

After a little experimenting, pretty_env_logger looked like a good solution for clear logging that can be easily toggled with environment variables.

Many of these logging events can be put in the Context and Module builder methods, keeping our module implementations nice and clean.

For logging events that can't be easily hidden away in builder methods, we can create macros to produce clear logs for common events.

One example would be the various checks we make when looking for files of a certain type. Here's a macro I threw together to make checkbox-like output to show what does and doesn't meet the criteria for a language:

starship/src/modules/nodejs.rs

Lines 53 to 56 in c63d7ad

	trace!("{}", dir_entry.to_str().unwrap_or("Unable to parse DirEntry"));
	trace_checkbox!(is_js_file(&dir_entry), "*.js file");
	trace_checkbox!(is_node_modules(&dir_entry), "node_modules folder");
	trace_checkbox!(is_package_json(&dir_entry), "package.json file\n");

Also, let's try to get our logs looking pretty. 😉
Signale does a good job of looking stylish while being informative.

Describe alternatives you've considered

An alternative would be to generate log files instead of outputting logs based on environment variables. Since the starship prompt is stateless, it should be pretty easy to reproduce faulty prompt outputs in the same directory. That being the case, I don't think there is much need for a persistent log.
Of course, I'm open to discussing if there are other reasons to log to a file!

Compatibility with login shell

The doc told me to add this line to my ~/.zshrc

eval "$(starship init $0)"

However, $0 is -zsh when I use zsh as my login shell. The command above would throw me an error

error: Found argument '-z' which wasn't expected, or isn't valid in this context

Maybe using string substitution to remove the prefix '-' is better?

eval "$(starship init ${0#'-'})"

Implement the prompt segment for package version (📦)

Feature Details

Implement the prompt segment containing the package version of the package present in the current directory.

Node.js

Should show package versions from Node.js projects from the package.json file, in the version key.

Rust

Should show package versions from Rust projects from the Cargo.toml file, in the package.version key.

Implementation

The original spaceship implementation showing ⚠️ when the package is missing a version was the source of a lot of confusion, so I don't personally think it should be added. I'm open to discussing the implementation.

The implmentation done for spaceship can be referenced here: https://github.com/denysdovhan/spaceship-prompt/blob/d9f25e14e7bec4bef223fd8a9151d40b8aa868fa/sections/package.zsh

prompt misalignment when line_break disabled

Bug Report

I think this is a bug

Current Behavior

cursor appears on the incorrect line when setting line_break.disabled to be true

Expected Behavior

cursor should appear on the same line as the prompt

Additional context/Screenshots

Environment

• Starship version: 0.3.2
• Shell type: fish
• Shell version: 3.0.2
• Shell plugin manager: omf
• Terminal emulator: alacritty
• Operating system: OSX 10.14.5

Starship Configuration

# ~/.config/starship.toml

[line_break]
disabled = false

Add compatibility with most Zsh plugin managers

Feature Request

It's definitely a nice feature to have compatibility with most Zsh plugin managers, so that people don't have to adapt to either a new shell or plugin manager to just use our prompt.

Is your feature request related to a problem? Please describe.

I currently can't install this prompt using antibody, my preferred Zsh plugin manager.

Describe the solution you'd like

A one line to install the Starship prompt with my favoured plugin manager (I'm taking inspiration from the pure prompt).

Describe alternatives you've considered

✨ · Allow the git module to be more interactive!

Feature Request

I believe that there could be quite a few cool improvements to the git module to make it more interactive! There are so many extra icons in nerd fonts and we could use them for different things.

Making a commit, switching branch, making a pull-request or merging? Switch to the appropriate icon!

Using GitLab or GitHub as your remote? There are also icons for that!

Investigate integration test failures occurring on Windows

Bug Report

✨ My Windows computer is in storage at the moment, so I don't have the means to easily debug this issue. Any help would be appreciated!

Current Behavior

The directory::directory_in_root integration test fails on Windows, printing an empty string for the directory module.

An example run could be found here:
https://dev.azure.com/starship-control/starship/_build/results?buildId=849&view=logs&j=53d55d64-8509-53fa-5dcb-02bd85116cd5

Expected Behavior

Root directories print on Windows as they do on other platforms.

Additional context/Screenshots

Environment

• Starship version: starship 0.2.0
• Shell type: N/A
• Shell version: N/A
• Shell plugin manager: N/A
• Terminal emulator: N/A
• Operating system: Windows 10

Add alternative Character module configuration for the color-blind

Feature Request

Add the ability to add a character to the prompt in the case of a non-zero exit code. Other prompts use things like 🚫, or 💥, or a red X. Having it configurable would be best, of course.

Is your feature request related to a problem? Please describe.

As someone who is red-green colorblind, it is very difficult to distinguish between the green and red arrows. Watching the intro animated GIF, I didn't even realize that the prompt changed after running false until I was reading through the documentation.

Describe the solution you'd like

Add a configurable character to the prompt in the case of the previous command exiting non-zero.

Describe alternatives you've considered

Possibly replacing the character prompt with something else? So instead of ➜, maybe an X? I'm not sure where adding or replacing would be best, and would be very happy with either option.

Implement the prompt segment for Rust version (🦀)

Feature Details

Implement the prompt segment containing the currently running Rust version.
Instead of the 𝗥 symbol used in spaceship, I suggest we use the 🦀 emoji instead, as is planned in spaceship v4: spaceship-prompt/spaceship-prompt#516

Should show if:

• rustc is available as a command
• The current directory contains
  • Cargo.toml
  • *.rs

Implementation

This should be implemented similarly to the Node version section:
https://github.com/starship/starship/blob/d620f9116b2b342ff22978ae87a78cdfccefb0de/src/modules/nodejs.rs

The implementation used in spaceship is a good reference to have:
https://github.com/denysdovhan/spaceship-prompt/blob/d9f25e14e7bec4bef223fd8a9151d40b8aa868fa/sections/rust.zsh

Implement module style configuration

Feature Request

Is your feature request related to a problem? Please describe.

Now that we have module configuration implemented for many of the prompt's modules, it would be a good time to look into implementing style configuration to be able to alter the default style values.

Describe the solution you'd like

Style configuration would be provided in string form, specifying the color and text style to be applied. For instance, you could set a module's style to "red", but "bold underlined red" would also work.

Here's an example:

[character]
style_success = "bold green"
style_failure = "red"

Describe alternatives you've considered

An alternative option would be to use an array or object to specify the color and text style, but I think that using strings would be much easier to read.

Discussion: Installation process

As we get closer and closer to a primitive MVP of starship, we should start discussing our approach to installing the prompt. Here are a few possible implementations that I've been thinking about. I'd be open to hearing how you would suggest going about installing starship.

What is needed

• starship is added to $PATH
• The following is executed as the prompt: starship $status

Possible Options

Set the prompt via config file

Summary

Installing starship via apt-get or brew runs a post-install script that appends the shell config file with a script that overwrites the prompt.

Details

• Add the following to your config file:

  # ~/.config/config.fish
  eval (starship init)
  
  # ~/.bashrc or ~/.zshrc
  eval "$(starship init)"

• starship init will output the following based on the shell being used:

  # fish
  function fish_prompt; starship $status; end
  
  # bash
  PS1="$(starship $?)"
  
  # zsh
  PROMPT="$(starship $?)"

Pros

• Easy for users to install manually
• Easy to automate
• Easy to uninstall
• Easy to troubleshoot

Cons

• Will overwrite the prompt set by a shell package manager or framework

Conclusion

Metric	Rating
Easy to implement	★★★★★
Easy to install	★★★★★
Works as expected	★★☆☆☆

---

Automatically install via shell package manager or framework

Summary

Installing starship via apt-get or brew runs a post-install script that identifies the shell package managers or frameworks installed, and will install starship with the API of those respective package managers and frameworks.

Details

• Identify the prompt used by the user
• Identify which shell package manager or framework is being used (if any)
• Run necessary commands to install the prompt

## Fish is the primary prompt

# fisher is installed
fisher add starship/fish

# oh-my-fish is installed
omf install starship/fish
omf theme starship

## ZSH is the primary prompt

# oh-my-zsh is installed
git clone https://github.com/starship/zsh.git "$ZSH_CUSTOM/themes/starship"
ln -s "$ZSH_CUSTOM/themes/starship/starship.zsh-theme" "$ZSH_CUSTOM/themes/starship.zsh-theme"

# Antigen is installed
antigen theme starship/zsh

# Antibody is installed
antibody bundle starship/zsh

# zgen is installed
zgen load starship/zsh starship

Pros

• The most convenient solution for users
• Compatible with all supported package managers and frameworks

Cons

• Predicting which shell and package manager is being used by the user could be error-prone
• Will require implementation for each package manager
• Makes our installation process reliant on an API contract with each plugin manager and framework

Conclusion

Metric	Rating
Easy to implement	★☆☆☆☆
Easy to install	★★★★★
Works as expected	★★★★★

---

Interactive configuration prompts

Summary

Installing starship via apt-get or brew runs a post-install script that
asks the user a series of questions to determine the correct way to install the prompt.

Similar to how rustup is installed.

Rustup Installation Screenshot

Details

• Ask the user which shell they use
• Ask the user which package manager or framework they use
• Install the correct prompt based on the user's input

Pros

• Won't be installed using the incorrect method
• Less magic makes it easier to troubleshoot
• Clear to the user
• Compatible with all supported package managers and frameworks

Cons

• Requires user intervention
• Won't be able to install silently by default
• Will require implementation for each package manager
• Makes our installation process reliant on an API contract with each plugin manager and framework

Conclusion

Metric	Rating
Easy to implement	★★☆☆☆
Easy to install	★★★★☆
Works as expected	★★★★★

---

I think that a mix of the last two may be the way to go. We attempt to identify the shell and package manager being used by the user, we then verify with the user (much like rustup), and install it accordingly. The user would be able to customize the installation and override the identified shell and package manager.

It would also support a --silent flag to simply go with the predicted method, or an installation method could be specifically chosen with flags (e.g. --shell=zsh --install-with=antigen).

Exception thrown with 0.8.5 update

Bug Report

Current Behavior

Installed the new 0.8.5 update and now getting an exception thrown (see screenshot).

Expected Behavior

clean shell without errors

Additional context/Screenshots

Environment

• Starship version: 0.8.5
• Shell type: fish
• Shell version: 3.0.2
• Shell plugin manager: oh-my-fish
• Terminal emulator: iTerm
• Operating system: macOS 10.14.6

Relevant Shell Configuration

# ~/.config/fish/config.fish
eval (starship init fish)

Starship Configuration

# ~/.config/starship.toml
[git_branch]
symbol = ""

Possible Solution

Implement the prompt module for execution time

Feature Request

Implement the prompt segment showing the execution time of the last command. By default, the module will only be shown if the execution time of the last command if it took more than 2 seconds to execute.

Much like the jobs module, each shell will likely have its own say to track and retrieve execution time, so information about the last command's execution may need to be passed in as a flag during starship init.

Describe the solution you'd like

The implementation used in spaceship is a good reference for this module:
https://github.com/denysdovhan/spaceship-prompt/blob/5f0a747171cd171c578f9359da517545f60cc1da/sections/exec_time.zsh

Implement the prompt segment for Python version (🐍)

Feature Details

Implement the prompt segment containing the currently running Python version.

Should show if:

• python is available as a command
• The current directory contains
  • .python-version
  • requirements.txt
  • pyproject.toml
  • *.py

Implementation

The implmentation done for spaceship can be referenced here: https://github.com/denysdovhan/spaceship-prompt/blob/cd4bd15b8bada850d8f68c664e669b844aec0519/sections/pyenv.zsh

Add Elixir on starship

Feature Request

It could be really cool having Elixir (and if possible Erlang too) support on starship

Change how default config values are handed in the code

The most common way to handle default values for config options seems to be to attempt to look up the key in the toml, then assign a default value if that fails, something like config.get_as_type(key).unwrap_or(default_value). There are several potential problems I can see with this approach:

• It allows the user to typo keys in their config and not be warned about it (e.g. use_colour)
• It allows the programmer to typo keys in their code and not be warned about it (granted this should usually be caught on testing/code review)
• If the documentation and code have accidentally diverged, you have to go to the source code of the module to look up the correct default arguments.

A possible alternative would be to create a config manager class that holds enums of all the config options, along with their default values. You would then be able to query it by asking it for the value of the enum, e.g. we would replace

    let signed_config_min = module.config_value_i64("min_time").unwrap_or(2);

with

   let signed_config_min = module.get_config_value(config::min_time);

We could even start to encode things like implied arguments (if one value is specified in the config, then multiple other values are implicitly set to certain values), or incompatible arguments across modules (if doing A in one module, cannot do B in another) into this config manager, and give starship the ability to check the toml for correctness.

Advantages:

• Code that accesses invalid configuration options will not compile
• Since code now knows about all config options, it can check user's toml file for inconsistencies or invalid config values
• Simplifies reading in of options in module code

Disadvantages:

• Large initial pain to switch over
• Cannot immediately see default value from within module code
• Potential unseen complexities in implementation

Would this seem like a net positive for us, or does it seem closer to neutral for what we have at the moment?

Implement the prompt module for username

Feature Request

Implement the prompt module containing the name of the current user.

Should show if:

• The current user isn't the same as the one that is logged in ($LOGNAME != $USER)
• The current user is root (UID = 0)
• The user is currently connected as an SSH session ($SSH_CONNECTION)

The color of the module should be yellow, unless the user is root. In that case, the module color should be red.

Example

Describe the solution you'd like

This should be implemented similarly to the Node version section:
https://github.com/starship/starship/blob/c6ee5c6ac16d360ab1a44d097c91fe9f98f20f85/src/modules/nodejs.rs

The implementation used in spaceship is a good reference to have:
https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/user.zsh

Add configuration for reordering the prompt modules

Feature Request

🌱 This issue is open for first-time contributors to starship!

With a little bit of familiarity with Rust, you should be able to pick up this issue.
Please feel free to take your time with this one and ask any starship maintainers for help. 🙏
We're here to guide you on your way to mastery of the codebase! 😄

Is your feature request related to a problem? Please describe.

So far we have enabled configuration for many of the prompt's modules, but we haven't yet enabled users to configure the order in which the modules are shown in the prompt.

This would involve adding a configuration option for prompt_order that would accept an array of modules by their names. This would override the default prompt order.

Describe the solution you'd like

Similarly to how we have implemented the add_newline configuration below it, we would be accessing a config value to change the default behavior.

Describe alternatives you've considered

N/A

🐛 · Entering the Starship repository causes panic.

Bug Report

Current Behavior

Entering the Starship repository causes a Rust panic. Possibly a duplicate of #54.

Expected Behavior

The prompt would show and there would be no panic.

Additional context/Screenshots

Welcome to fish, the friendly interactive shell

~
➜ cd ~/Code

~/Code
➜ ls
starship  stringrev

~/Code
➜ cd starship/
thread '<unnamed>' panicked at 'called `Option::unwrap()` on a `None` value', src/libcore/option.rs:345:21
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::continue_panic_fmt
   6: rust_begin_unwind
   7: core::panicking::panic_fmt
   8: core::panicking::panic
   9: starship::modules::rust::segment
  10: starship::modules::handle
  11: rayon::iter::plumbing::Folder::consume_iter
  12: rayon::iter::plumbing::bridge_producer_consumer::helper
  13: std::panicking::try::do_call
  14: __rust_maybe_catch_panic
  15: rayon_core::join::join_context
  16: rayon::iter::plumbing::bridge_producer_consumer::helper
  17: rayon_core::job::StackJob<L,F,R>::run_inline
  18: rayon_core::join::join_context
  19: rayon::iter::plumbing::bridge_producer_consumer::helper
  20: std::panicking::try::do_call
  21: __rust_maybe_catch_panic
  22: rayon_core::join::join_context
  23: rayon::iter::plumbing::bridge_producer_consumer::helper
  24: std::panicking::try::do_call
  25: __rust_maybe_catch_panic
  26: <rayon_core::job::StackJob<L,F,R> as rayon_core::job::Job>::execute
  27: rayon_core::registry::WorkerThread::wait_until_cold
  28: rayon_core::registry::ThreadBuilder::run

Environment

• Starship version: Starship 0.1.0
• Shell type: fish
• Shell version: fish, version 3.0.2
• Shell plugin manager: fisher
• Terminal emulator: iTerm2
• Operating system: macOS Mojave 10.14.5

Relevant Shell Configuration

➜ cat ~/.config/fish/functions/fish_prompt.fish
function fish_prompt
  env RUST_BACKTRACE=1 starship prompt --status=$status
end

cat ~/.config/fish/config.fish
# Start or re-use a gpg-agent.
#
gpgconf --launch gpg-agent

# Ensure that GPG Agent is used as the SSH agent
set -e SSH_AUTH_SOCK
set -U -x SSH_AUTH_SOCK ~/.gnupg/S.gpg-agent.ssh

set PATH /Users/snuggle/.cargo/bin /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin

Add hostname module

Feature Request

Is your feature request related to a problem? Please describe.

When I was only using starship on one machine, it was pretty easy to keep track of where I was.

Now that I have it across 4 or 5, I find myself getting confused a little too often as to which host I'm actually on.

Describe the solution you'd like

A module like host from spaceship, which prints out the hostname of the system.

Reference implementation: https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/host.zsh

Describe alternatives you've considered

Nothing yet.

Implement module for Vi mode

I'm currently using spaceship prompt in zsh, which has vi mode indication for normal and insert mode (spaceship_vi_mode_enable). Does starship offers vi mode indication already?

If not, I'd like to leave as feature request.

I've seen it being implemented in two ways, with dual prompts, like ❯❯❯ or ❯ for insert mode and ❮❮❮ or ❮ for normal mode (could be configurable), or with an additional section, like, [I] ➜ and [N] ➜. sorin and pure prompts do the former, spaceship does the latter.

Prompt is frozen in bash/zsh

Bug Report

Current Behavior

On zsh and bash, the prompt seems to get "frozen" in the directory where starship init is evaluated, e.g. if I start the shell in the tmp directory, the prompt is always displaying tmp, even if I move somewhere unrelated.

Expected Behavior

Prompt should change based on current directory.

Additional context/Screenshots

Demo in bash--same thing happens in zsh.

Environment

• Starship version: starship 0.2.0
• Shell type: zsh or bash
• Shell version: zsh 5.7.1-dev-0, bash 3.2.57
• Shell plugin manager: zprezto
• Terminal emulator: iTerm2
• Operating system: MacOS

Relevant Shell Configuration

N/A

Starship Configuration

None

Possible Solution

I think this is being caused because bash/zsh evaluates VAR="$(starship prompt)" exactly once (when the variable is set) and then doesn't run starship afterwards.

I can think of two solutions to this: one is demoed in the above GIF which single-quotes the assignment to the variable, delaying its expansion until it's used in the prompt. The other would be to use a command hook (precmd in zsh, PROMPT_COMMAND in bash) to update the value of the variable every time the prompt is drawn. I don't have a good sense for which one would be more robust.

Python version not showing on python versions < 3.4

Bug Report

Current Behavior

Starship seems to detect a python project, however in my case, it seems to not be able to detect the version, even tho when I run python --version I get Python 2.7.15rc1

Expected Behavior

It should show the Python version in the prompt

Additional context/Screenshots

Environment

• Starship version: 0.1.0
• Shell type: fish
• Shell version: fish, version 2.7.1
• Shell plugin manager: oh-my-fish
• Terminal emulator: Tilix
• Operating system: elementary OS 5.0

Relevant Shell Configuration

set -U fish_user_abbreviations

export EDITOR="nvim"

export BAT_THEME="TwoDark"
export FLUTTER_HOME=/opt/flutter

export WINEARCH=win32
export WINEPREFIX=$HOME/.wine_x86

export GOPATH=$HOME/Development/Golang

# Spacefish configuration
export SPACEFISH_DIR_TRUNC=0

# PATH configuration
set -x PATH $PATH $FLUTTER_HOME/bin
set -x PATH $PATH $HOME/.config/composer/vendor/bin
set -x PATH $PATH $HOME/.yarn/bin
set -x PATH $PATH $HOME/.cargo/bin

# Loading autojump if installed
if test -f $HOME/.autojump/share/autojump/autojump.fish
    source $HOME/.autojump/share/autojump/autojump.fish
end

# Loading abbreviations if existing
if test -f $HOME/.config/fish/abbreviations.fish
    source "$HOME/.config/fish/abbreviations.fish"
end

Starship Configuration

// Doesn't exists

Possible Solution

Prompt panics in the root directory of a Rust project without a package.version

Bug Report

Current Behavior

Prompt panics with 'index not found' when navigating to the root of the https://github.com/tokio-rs/tokio codebase.

Expected Behavior

Prompt displays with the tokio dirname.

Additional context/Screenshots

Environment

• Starship version: Starship 0.1.0
• Shell type: fish
• Shell version: fish, version 3.0.2
• Shell plugin manager: fisher
• Terminal emulator: iTerm2 v3.2.9
• Operating system: macOS 10.14.4

Relevant Shell Configuration

N/A

Starship Configuration

N/A

Possible Solution

An .unwrap() should be replaced with more thorough error handling.

Implement the prompt module for Go version (🐹)

Feature Request

Implement the prompt segment containing the currently running Go version.
Use the hamster emoji (🐹) as the symbol for the module, and have a cyan module color.

Should show if:

• The current directory contains
  • go.mod
  • Godeps
  • glide.yaml
  • *.go
  • Gopkg.yml
  • Gopkg.lock
• The current directory is $GOPATH

Describe the solution you'd like

This should be implemented similarly to the Node version section:
https://github.com/starship/starship/blob/c6ee5c6ac16d360ab1a44d097c91fe9f98f20f85/src/modules/nodejs.rs

The implementation used in spaceship is a good reference to have:
https://github.com/denysdovhan/spaceship-prompt/blob/d9f25e14e7bec4bef223fd8a9151d40b8aa868fa/sections/golang.zsh

Starship Logo/Emoji

Feature Request

Is your feature request related to a problem? Please describe.

Starships are much much much faster than mere Spaceships.
(Perhaps because they use Rust for their navigational systems! 😛)

However the two emoji used in this project's description shows a rocket, a vessel powered by fossil fuels and using conventional rocket propulsion.

✨🚀

The Wikipedia article for a starship describes that:

"Fiction that discusses slower-than-light starships is relatively rare, since the time scales are so long."

And it goes on to say that the majority of Starships use faster-than-light technology such as the Alcubierre warp drive in which a potential starship would compress the space in front of it while expanding the space in front of it in order to "warp" space and time to travel between star-systems, interstellar travel, travel across star-systems.

The fastest two theorised examples of interstellar travel using somewhat conventional propulsion systems (Both using nuclear-assisted engines) are Project Daedalus and Project Longshot which would've taken approx 50 years and 100 years respectively to travel to two of the closest known stars in our galaxy and would've required a nuclear fusion rocket which does not exist yet.

In short, it's largely impractical to try to travel between star-systems with rockets.

---

Describe the solution you'd like

Let's have a look at some starships in science fiction, thanks to this Wikipedia article!

USS Voyager, Star Trek: Voyager, NCC-74656

Andromeda Ascendant

Theoretical Animation of Warp Drive, Star Trek: Beyond

The combination of :comet: and :milky_way: would be much more representative of a starship, showing a warp-bubble as a blurry streak across space, travelling through a galaxy at more-than-theoretical speeds.

A spaceship ✨🚀 is typically capable of interplanetary spaceflight whereas a starship ☄️🌌 is typically capable of interstellar spaceflight and because it's moving so fast it would be a mere blurry smear of stretched-out space crossing starsystems.

Screenshot of Proposed Changes

---

What do you think, are there any emoji that's even more suitable? I'd love to hear opinions! 💕 🌈

Thank you, live long and prosper, keep being awesome! 🖖

🙈· Missing font dependencies!

Bug Report

Current Behavior

The git section currently is missing an icon. I believe this is due to Nerd fonts not being installed automatically.

Expected Behavior

The git section should show the correct icon!

Additional context/Screenshots

Environment

• Starship version: Starship 0.1.0
• Shell type: fish
• Shell version: fish, version 3.0.2
• Shell plugin manager: fisher
• Terminal emulator: iTerm2
• Operating system: macOS Mojave 10.14.5

Relevant Shell Configuration

➜ cat ~/.config/fish/functions/fish_prompt.fish
function fish_prompt
  env RUST_BACKTRACE=1 starship prompt --status=$status
end

cat ~/.config/fish/config.fish
# Start or re-use a gpg-agent.
#
gpgconf --launch gpg-agent

# Ensure that GPG Agent is used as the SSH agent
set -e SSH_AUTH_SOCK
set -U -x SSH_AUTH_SOCK ~/.gnupg/S.gpg-agent.ssh

set PATH /Users/snuggle/.cargo/bin /usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/MacGPG2/bin

Possible Solutions

This could be handled by a package manager or an install script!

Starship doesn't support /usr/local/bin/zsh

Bug Report

Current Behavior

When running zsh under the name /usr/local/bin/zsh on MacOS, there is an error:

/usr/local/bin/zsh is not yet supported by starship.
For the time being, we support bash, zsh, and fish.
Please open an issue in the starship repo if you would like to see support for /usr/local/bin/zsh:

and I'm dumped back in to my default zprezto prompt.

Expected Behavior

Things should work fine: /usr/local/bin/zsh is decidedly a version of zsh.

Additional context/Screenshots

Easy workaround for me: just make iTerm2 start the profile under the name zsh instead of /usr/local/bin/zsh. However, there may be certain edge cases where this isn't possible (e.g. you need a specific version of zsh for some reason or another and have to specify the absolute path).

Other potentially useful info:

• This isn't unique to iTerm2: running /usr/local/bin/zsh from MacOS's default Terminal will also trigger this error.
• This error does not seem to affect my Linux desktop (running same versions of zsh/starship).
• This does not affect fish, even when it's invoked as /usr/local/bin/fish, on any of the systems/terminal emulators I tried.

Environment

• Starship version: starship 0.2.0
• Shell type: zsh
• Shell version: zsh 5.7.1-dev-0
• Shell plugin manager: ZPrezto
• Terminal emulator: iTerm2
• Operating system: MacOS 10.14.5

Relevant Shell Configuration

# Source Prezto.
if [[ -s "${ZDOTDIR:-$HOME}/.zprezto/init.zsh" ]]; then
  source "${ZDOTDIR:-$HOME}/.zprezto/init.zsh"
fi

#Load theme
autoload -Uz promptinit
promptinit
prompt minimal

eval "$(starship init $0)"

Starship Configuration

I can't seem to find it :(

Even running a find over my entire home directory pulls up nothing.

Possible Solution

While I don't have a solid fix in mind, I'm making it a goal to learn a little Rust right now and I'd be happy to try to work on this (unless you think it would be easier to fix yourself). I tried implementing a quick fix using std::path::Path, but I couldn't quite get it working before some other work dragged me away (you have to use OsString/OsStr to use Path, and there's a whole lotta Options going on when trying to match.)

Can starship change terminal title?

This might be a dumb FAQ, but I couldn't figure it out. I always like to have my prompts change the title of my terminals as I change directories. In the old days I added bits to PS1 that the internet told me did this, and it did. However, since trying out Starship (which I like) my title isn't changing anymore.

Is there something I can add to the toml file that will enable this?

Implement the prompt module for jobs (✦)

Feature Request

Implement the prompt segment indicating that there are currently running jobs.
The ✦ symbol has been the default symbol for the module, with a blue module color. If there is more than 1 job running, a numbered indicator is shown with the number of jobs running.

It appears that fish has its own jobs binary, so testing will be needed on fish, zsh, and bash to ensure that the implementation is consistent across the shells.

Describe the solution you'd like

This should be implemented similarly to the Node version section:
https://github.com/starship/starship/blob/c6ee5c6ac16d360ab1a44d097c91fe9f98f20f85/src/modules/nodejs.rs

The implementation used in spaceship is a good reference:
https://github.com/denysdovhan/spaceship-prompt/blob/5f0a747171cd171c578f9359da517545f60cc1da/sections/jobs.zsh

Create pre-populated GitHub issues from starship directly

Already dreaming about features for v2.0. 😴💭
@sirMerr had a great idea that I wanted to share with everyone!

In order to do away with a lot of the headache associated with creating GitHub issues for bug reports, it would be pretty cool if we could pre-populate much of the issue based on the user's local installation.

When the user uses starship bug-report, a link will be generated with pre-populated fields for the following fields:

• OS
• Shell
• Plugin manager
• Shell configuration
• Starship configuration

Here's an example of how a pre-filled GitHub issue would look: Example Link
By making use of the query params accepted by GitHub when creating new issues, we can make bug reporting that much easier! 😄

Add prompt support for PowerShell

Feature Request

Support for PowerShell would be extra cool!

I'd be more than happy to put together a pull request for this.

Is your feature request related to a problem? Please describe.

Cannot use Starship if workflow is mainly with PowerShell

Describe the solution you'd like

Add support for PowerShell for the Starship prompt

Describe alternatives you've considered

Using zsh/fish via Windows Subsystem for Linux, and invoking powershell scripts from there. But obviously not as nice as having it in PS

Option to disable directory truncation in git repo

Feature Request

Right now, Starship truncates the directory when inside a git repo to only show the segments of the path that are in that repo.

Describe the solution you'd like

I'd like to be able to opt-out of the truncation for git repos and fall back to the general settings on truncating paths (i.e. respecting the truncation length variable in the directory module.

Describe alternatives you've considered

An option to disable truncation of the directory globally (i.e. both inside and outside of git repositories) would also solve my issue.

Add current time to prompt

Feature Request

It'd be great if the current time was displayed in the prompt line.

Something like:

Implement the prompt segment for git branch name and status

Port the functionality present in spaceship for the git_branch and git_status segments.

The following files can be used as reference for the spaceship implementation:
https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/git.zsh
https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/git_branch.zsh
https://github.com/denysdovhan/spaceship-prompt/blob/master/sections/git_status.zsh

To retreive repo information, we will be using git2, which is already currently used in the directory section.

Add Crystal on starship

It is heavily inspired by Ruby' syntax, so you can simple adapt the current implementation.
Website: https://crystal-lang.org/

Organization name

I was hoping to create the "starship" org, but it looks like this GitHub account has been squatting the name since 2012: https://github.com/starship.

I've made a GitHub support ticket requesting access to the name, so hopefully we'll be able to use it for our org. Before I pull the trigger, do we have any other name proposals?

• astronauts (also parked but would be fun)
• starship-prompt (the backup if we can't get "starship")

RFC: Prompt configuration

Summary

Using a TOML configuration file ~/spaceship.toml instead of how environment variables were used in spaceship.

Motivation

I would like to reconsider how we should be doing prompt configuration. Historically we have had all configuration done with environment variables:

SPACESHIP_PROMPT_ORDER=(
  dir,
  ruby
)

# DIR
SPACESHIP_DIR_PREFIX='' # disable directory prefix, cause it's not the first section
SPACESHIP_DIR_TRUNC='1' # show only last directory

# RUBY
SPACESHIP_RUBY_PREFIX="ruby:("
SPACESHIP_RUBY_SUFFIX=") "
SPACESHIP_RUBY_SYMBOL=""

This has lead to a few issues:

• Increasing granularity of configuration meant longer and longer variable names
• Unable to use more expressive data types in configuration
• Bloating of environment variables list (spacefish is >50% of mine)

Here's an example of that same configuration in TOML:

segment_order = [
  "dir",
  "ruby"
]

[dir]
prefix = ""
truncation = 1

[ruby]
prefix = "ruby:("
suffix = ") "
symbol = ""

It didn't feel like we had enough nesting to make the complexity of JSON worthwhile as a config file format:

JSON Example

{
	"segmentOrder": [
		"dir",
		"ruby"
	],

	"dir": {
		"prefix": "",
		"truncation": 1
	},
	"ruby": {
		"prefix": "ruby:(",
		"suffix": ") ",
		"symbol": ""
	}
}

YAML also looks like a very promising option. It is arguably easier to read than TOML, but begins to be difficult to work with when you have any nesting, as it's completely indentation-based.

YAML Example

segment_order: 
  - dir
  - ruby

dir:
  prefix: ""
  truncation: 1

ruby:
  prefix: "ruby:("
  suffix: ") "
  symbol: ""

Where I think light-nesting will come to be useful is if we were to support individual styling of prefixes and suffixes, like in this example:

[ruby]
symbol = ""
color = "cyan"

  [ruby.prefix]
  color = "magenta"
  text = "ruby:("

  [ruby.suffix]
  color = "magenta"
  text = ") "

The same thing in YAML becomes difficult to parse and write:

ruby:
  symbol: ""
  color: "cyan"
  prefix:
    color: "magenta"
    text: "ruby:("
  suffix:
    color: "magenta"
    text: ") "

Drawbacks

• TOML is not the most well-recognized of configuration file formats, so there will need to be some clear documentation written around config files.
• Error messaging will need to be added in the event that the TOML file is unable to be parsed. This was not an issue in the past when working with environment variables.

Add Nim on starship

This programming language is close to v1.0 release (currently v1.0 RC2) and it is used by some companies, for example Status is implementing an Ethereum 2.0 client.
Its syntax is python-ish and has a package manager called Nimble.
Website: https://nim-lang.org/

Starship Prompt confuses bash/zsh cursor location

Bug Report

Sorry about all the bug reports I've been generating recently! On the bright side, this is probably the last thing that's been bothering me in day-to-day use. Unfortunately, it seems a tad tricky to fix...

Current Behavior

In ZSH, using tab-completion with starship confuses the prompt, and causes some characters to be duplicated if there's more than one completion option. Once the extra characters are printed, the "zero point" of the shell seems to shift over, and you can no longer overwrite them. It also affect character wrapping on the right edge of the screen.

Similar behavior exists in bash, but it's a lot subtler (possibly because bash does not redraw certain areas). You have to mess with history to get it to show up.

Expected Behavior

Prompt should not interfere with TAB-completion or anything involving cursor jumps.

Additional context/Screenshots

Environment

• Starship version: 0.2.0
• Shell type: zsh
• Shell version: zsh 5.7.1-dev-0
• Shell plugin manager: antibody
• Terminal emulator: iTerm2
• Operating system: MacOS 10.14.5

Relevant Shell Configuration

Replicates in a shell where the only line in .zshrc is eval $(starship init zsh).

Starship Configuration

None.

Possible Solution

I don't have an idea for the solution but I think I know why this happens.

If you capture the output of starship prompt and dump it into a file, you get the following:

^[[1;36m/private/tmp^[[0m
^[[1;32m➜^[[0m

There are 11 non-printable characters on the second line of that prompt, and the space that's left between the start-of-prompt and start-of-unerasable-characters is exactly that many characters wide.

If you disable the color setting in the characters module, both the tab-completion issue and the character wrapping issue go away:

This leads me to conclude that the shell is counting the color escape codes as "printed characters" and placing the cursor too far to the right as a result.

If we were setting PROMPT/PS1 via a hand-coded shell sequence, the solution would be to escape characters to indicate to the shell that these sequences are zero length:

• \[ ... \] for bash [1][2]
• %{ %} for zsh

but we're not--the color codes are coming from the ANSI library, and I don't see a way to tell the library to wrap the escape codes in a shell-specific escape sequence.

Add starship prompt configuration file

Implement starship prompt configuration based on the conversation that took place in #10.

Feature Design

• Read a starship.toml file placed in $XDG_CONFIG_HOME
  • If $XDG_CONFIG_HOME is not set, read $HOME/.config/starship.toml
• User configuration is stored in the Context struct for use across segments
• Use Segment.name as TOML table keys

PR should include

• Demonstrate configuration by having char symbol be replaceable
• Add integration test for char being replaced

Support `cmd_duration` robustly in bash

Right now, we don't have a foolproof way to support command timing in bash, which requires both overriding PROMPT_COMMAND and trapping DEBUG (analagous to precmd/preexec in zsh).

There's no real way around overriding PROMPT_COMMAND at the moment (and if the user is installing our prompt, they presumably don't care about their old PROMPT_COMMAND), but breaking existing DEBUG traps could disable other functionality that isn't related to the prompt.

It seems that no two bash frameworks handle this the same way--rcaloras's preexec framework uses a preexec_functions array, while bash-it uses a hook to add preexec functions. Until we can support it robustly (or determine that we don't care if we break user's DEBUG traps), we'll keep it out of the bash init scripts.

The first-draft implementation of timing support for bash was as follows:

starship_preexec() {
    if [ "$PREEXEC_READY" = "true" ]; then
        PREEXEC_READY=false;
        STARSHIP_START_TIME=$(date +%s);
    fi
};
starship_precmd() {
    STATUS=$?;
    if [[ $STARSHIP_START_TIME ]]; then
        STARSHIP_END_TIME=$(date +%s);
        STARSHIP_DURATION=$((STARSHIP_END_TIME - STARSHIP_START_TIME));
        PS1="$(starship prompt --status=$STATUS --duration=$STARSHIP_DURATION)";
        unset STARSHIP_START_TIME;
    else
        PS1="$(starship prompt --status=$STATUS)";
    fi;
    PREEXEC_READY=true;
};
if [[ $preexec_functions ]]; then
    preexec_functions+=(starship_preexec);
    precmd_functions+=(starship_precmd);
    STARSHIP_START_TIME=$(date +%s);
fi;
dbg_trap="$(trap -p DEBUG | cut -d' ' -f3 | tr -d \')";
if [[ -z $dbg_trap || "$dbg_trap" = "starship_preexec" ]]; then
    trap starship_preexec DEBUG;
    PROMPT_COMMAND=starship_precmd;
    STARSHIP_START_TIME=$(date +%s);
else
    PROMPT_COMMAND=starship_precmd;
    unset STARSHIP_START_TIME;
fi

Add Online Connectivity

Feature Request

Not sure if it fits into alot of peoples use case but perhaps we could add a config option to show online connectivity. Just saw this lib below so most of the hard work is done.
Online Rust Library

Describe the solution you'd like

Have a module that will show an icon with current online strength or perhaps we could use the current speeds? upload download etc.

Describe alternatives you've considered

May not be fore everyone but could be a nice little feature.

Starship Explainer

Feature Request

I have used quite a few pre-made shell prompts in the last N years, and one thing that's always gotten to me is that it's very irritating to figure out what that weird symbol that just popped up at the edge of your prompt is. Inevitably, one of three things happens:

• I just ignore it and it never pops up again.
• It eventually pops up often enough that I open a web browser, go to the website of the prompt/google around, and eventually figure out what it is, at the cost of a 5 minute interruption to what I was doing.
• I'm mucking through the code to customize something and accidentally stumble over it.

To this day, I still don't know what all the git symbols in my ZPretzo prompt mean--I just run git status and worry about it there.

Is your feature request related to a problem? Please describe.

There ought to be an easier way to discover what all these cool glyphs mean.

Describe the solution you'd like

A command that can be used (maybe starship explainer) and it will explain what every part of the prompt means.

Pros: allows easy discovery of what each part of the prompt means.

Downsides:

• could become very complex to build if the configuration grows too much
• would have to be maintained/changed every time the prompt is changed
• layout could be challenging.

Describe alternatives you've considered

Ideally you could mouse-hover over the prompt section to get a pop-up, but that depends pretty heavily on what terminal emulators are available.

It might be possible to hyperlink each part of the shell to a page that explains it, but (a) this also depends really heavily on the terminal emulator and (b) I would definitely click on those by accident, all the time.

Create a benchmarking CI step, comparing module performance between that PR and master

Feature Request

Create a CI script (probably with GitHub Actions), that will run the same benchmark on the branch of the PR and on master, surfacing considerable changes in build performance.

Benchmarks can be run in starship by running cargo bench with Rust nightly.

An example of an existing Action that does this would be https://github.com/zeit/next-stats-action.
Here is an example of its output: vercel/next.js#7154 (comment)