Starship: The minimal, fast, and customizable prompt for any shell

nushell does that out of the box:

    > history | get 82076
    ╭─────────────────┬──────────────────╮
    │ start_timestamp │ 2025-06-24 16:46 │
    │ command         │ mpc play         │
    │ cwd             │ /home/work       │
    │ duration        │ 1ms              │
    │ exit_status     │ 0                │
    ╰─────────────────┴──────────────────╯

I never bothered configuring my prompt at all because, inside emacs, I could already see most of what I needed in the editor itself.

In fact, I only set up Starship when I started to do more pairing. It wasn’t for my benefit as much as it was for those watching my screen and checking the work, especially when operating on prod and confirming what we wanted to run. I just load up a separate terminal app for that so I don’t have to walk people through my setup.

Current time in a more human-readable format is very helpful sometimes. Also, the exit status of the previous command, if nonzero, is also very helpful when anything fails.

The exit code of the last command is useful for similar reasons.

You could probably (I haven’t tested it) append the run time as a comment to the history using something like PROMPT_COMMAND and `history -r <(…)`, instead of cluttering the prompt with it. And the start time is already in the history, using HISTTIMEFORMAT.

For personal workstation, the current directory is enough. Maybe I change the color based the status of the last command. That’s pretty much the only information I need before entering any command. Everything else can be accessed when I really need it.

> Personally, over time, I have stopped caring too much about prompt customization.

For a while, I tried a couple of Christmas tree prompts which included all kinds of condensed Git status and other bells and whistles, but eventually tired of them and settled on:

- Exit status of the previous command, if nonzero.

- Current time, HH:MM, 24 hour format.

- user@host, red if euid 0, green otherwise.

- Current directory, shortened if the path has three or more elements, with home directory recognition.

- Current directory, full path, echoed as hardstatus and hence appearing in the terminal window title.

- The name of the current branch if within a Git repo.

- Prompt character, dollar/hash sign.

All those elements are meaningful to me, inasmuch as I can quickly orient myself using that information and explore further if I notice anything out of the ordinary.

I'm pretty sure that megaprompt programs like Starship could produce the above, but I like obtaining a familiar prompt with a minimum of external dependencies, and so have written it all in Bash, then ported to Zsh and various Korn shells, which was quite tricky. It probably wouldn't work on Xenix 286, but anything newer has a fighting chance.

I'm senior, been working in the industry for closing on 25 years now. I usually avoid anything "ohh shiny".

For most of my career I used a very simple PS1:

    export PS1="\[\033[1;32m\][\t \u@\h \w]\\$\[\033[0m\] "

I've tried prompts in the past, and they mostly annoyed me, or never showed me useful information. I've been a happy starship user for several years now. I've got the config tweaked so that it only shows me things I specifically care about. It's lightning fast.

As a counterpoint, one of the most useful customizations I've made to my prompt is to emit the exit status of the prior command. Knowing that something failed is a useful signal, esp. when sometimes the thing failing just fails to emit any output that indicates that it failed.

I only emit it if the prior command fails, too, so it doesn't clutter things the 90% of the time things are working.

  » true
  » false
  (last command returned 1.)
  » 

It's also useful the other way: when a program emits and error and exits with "success".

I think we can generalize this into the overall computing environment. When I was younger, I was that kid building my whole OS from source via Gentoo, with all the CPU-specific flags and optimizations. I had a very detailed window manager configuration (fwvm2 maybe?), a .bashrc full of aliases and functions for every occasion. And yes, a custom prompt.

I think these kinds of over-optimization rabbit holes are a good learning experience, but I compare it to woodworking. A woodworker just starting out will spend most of his/her time building or refining the tools they need, learning techniques, coming up with ideas/designs and testing them, etc. But eventually the point comes where you have to get Real Work done and the tools and jigs have to wait until the weekend.

Linux is still my favorite desktop OS, but these days I just run Debian and KDE because "free time" is not a thing I have anymore and I care more about getting things done than having the most optimal computing experience.

I’m “very senior” (as in decades of _Unix_ use senior) and I like it in minimal mode because it’s just so much less hassle than all the other zsh stuff I had been using for a couple of decades. Not sure if you expected replies to be full of all the JavaScript kids that use emojis in logging messages, but apologies if so :)

I'm senior, been working in the industry for closing on 25 years now, majority of that dealing with *nix systems of various descriptions. I usually avoid anything "ohh shiny".

I've tried prompts in the past, and they mostly annoyed me, or never showed me useful information. I've been a happy starship user for several years now. I've got the config tweaked so that it only shows me things I specifically care about. It's lightning fast.

You can make it as small as you want. Every single feature can be disabled. At the moment mine is relatively minimal

    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"""

Compared to other shells and prompts, the configuration is really straightforward and minimal if you want something mildly complex.

Yeah this isn't minimal, this is maximalism - more information, more characters. They should just embrace being a maximalist prompt.

Mine is an even thinner arrow.

# clean, simple, minimal

  PROMPT='%{%F{red}%}%~ %{%F{yellow}%}% › %{%F{reset_color}%}%'

Starship is very fast, taking only a couple of milliseconds to gather the data (and you can easily configure it to minimise what it'll spend time gathering). It's night and day compared to other ones I've tried, where the hundred millisecond-ish delays annoyed me.

we optimize for code runtime but not for our own typing latency

100ms optimization is a lot different for a CPU or a human brain. I'm not defending having the entire system log dumped out on every prompt but a few amenities are worth a few milliseconds computation time for a human.

Besides, I don't see how, for example , having your prompt take those 100ms to print a git branch or status breaks your "flow" yet having to type out the commands yourself and taking longer doing it doesn't.

Its a balance between bloat and and usability like so many other things, but, to me at least, being on either extreme of bloat or extreme-minimalism seems counterproductive.

The delay is certainly frustrating. I use a patched version of kitty terminal that moves starship prompt to the bottom of the window, similar to vim and emacs. Since modeline updates are asynchronous, the shell prompt is very snappy even in big git repos. The downside is that you have to patch kitty and I never bothered to test my personal pet project on anything else than Linux.

https://github.com/mbachry/kitty-modeline

Could prompt tools like this use TUI-style features to edit the displayed prompt after releasing it back to the user? So if kubectl, git, or aws cli takes 200ms to finish it doesn't matter, the data from the output of these commands will appear a few moments after the prompt has been released to the user, so the user doesn't feel like they're waiting for the prompt to be ready.

> we optimize for code runtime but not for our own typing latency

Don't the layers of frameworks mean that the opposite is true.

counter-point: having to constantly track git status in your head, and needing to type commands to remind yourself, is a far bigger distraction. Optimize to avoid context switching, not for a few ms latency.

FWIW, I switched from zsh default to starship and didn't notice any perceptible difference. But I certainly notice when I mess up my git commits!

If you're used to, say, VS Code or the GitHub online editor where the lag between pressing a key on the keyboard and a corresponding character appearing on the screen can be on the order of tens of thousands of milliseconds, then 100 ms will seem like lightning.