If you use the command line, you would most certainly benefit from using a good prompt system instead of the default one. Among the seven most known prompt systems, some have a better design and some better support certain features.
The main conclusions are:
- If you are looking for the design providing the best overall user experience, you should probably use Liquid Prompt.
- If low latency is more important to you than features, you should bet on PowerLevel10k.
- If you are a developer juggling many toolsets, Starship seems to be the best option for you.
This article is divided in two main parts: the first one introduces the subject and presents the main assessments, and the second part goes into details about designs and features. The conclusion gives advice about which prompt to choose, and opens up some ideas on the future of prompt systems.
Disclaimer: I am the original author of Liquid Prompt. At first, I did this extensive study wondering whether or not I should keep my interest in Liquid Prompt or switch to another system. I will try here to explain here why I still think it is one of the bests prompts on the market.
All of the compared prompt systems are good free software, so I will focus here on the usefulness of their feature set, rather than digging into code quality or ease of installation.
There are two kind of computer scientists: those who use the command line, and those who are retired. Even developers who embrace highly integrated development interfaces have some kind of terminal available in some panel of their IDE. Like it or not, the shell is a core part of everyday life for most of the people expecting their computer to work for them.
Now the shell actually has access to a lot of information about the computer. And most of this information is about the current state of the work environment, which is of the highest interest to the user. However, by default the shell only shows very little information unless you ask specifically for it. Furthermore, the only location on the screen available for the permanent display of anything is the "prompt".
The prompt is this string of characters displayed right in front of the line where you type your commands.
In the most common default configuration, it displays only three pieces of information: the user, the hostname, and the path —user@hostname:path $ .
But it can display more! And this is the objective of prompt systems. Those "prompts" (to be short) actually add a lot of information to this area of the command line. For example, the most common feature is to display the state of the Git repository the user is in.
As is usual with software that targets power users, the market is highly fragmented: there are a ton of available prompt systems. A lot of people seem to enjoy programming their prompt from scratch and drop it on GitHub.
For the purpose of this article, I only considered 7 prompts. Among the most popular, as per the number of fan articles seen by Google and as per stars on GitHub:
- PowerLevel10k, the most popular,
- Starship, the one programmed in Rust, and Spaceship, its origin (in the following, both are considered as one system, given their similarity, but you would probably want to use Starship anyway),
- Powerline, coming from status lines,
- Pure, the surprisingly successful minimal one,
- Oh-My-Posh, the portable one,
- Liquid Prompt, the eldest (historically the first to appear).
Note that the number of stars is not necessarily correlated with the age of the software. For instance, Liquid Prompt first started in 2010, while Powerlevel* started in 2015 and Starship in 2019.
The rationale of a prompt system is that it is useful to have immediate access to the current state of the system. Seeing a state change right where the user usually looks is a very good feedback on their actions. But of course this feedback should not get in the way of how the user works.
States should be chosen and displayed according to their importance for the user's work. More precisely, a good prompt is a prompt which is:
- focused: it targets states that are actually useful to the user during a work session,
- seamless: it does not product friction with the user workflow,
- scoped: it targets states that can change by themselves or be changed by the user,
- measured: it embraces the fact that some states change less often than others (and thus avoids being just a collection of states that only rarely change),
- accentuated: it makes more visible the feedback for more important state changes, while not polluting the visibility of stable/anecdotal states,
- configurable: be easy to immediately adapt the display of information, if needed.
To state it simply, a good prompt system must be well designed.
My assessment of the overall design of the contestants is summarized in the following table:
| Prompt | Focused | Seamless | Scoped | Measured | Accentuated | Configurable |
|---|---|---|---|---|---|---|
| Liquid Prompt | 🌟🌟🌟 | ⭐⭐ | ⭐⭐ | 🌟🌟🌟 | 🌟🌟🌟 | 🌟🌟🌟 |
| PowerLevel10k | ⭐⭐ | 🌟🌟🌟 | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ |
| Oh-My-Posh | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐ | ⭐⭐ |
| Pure | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐⭐ | ⭐ | ⭐⭐ |
| *ship | ⭐ | ⭐⭐ | ⭐ | ⭐ | ⭐ | ⭐⭐ |
| Powerline | ⭐ | ⭐⭐ | ⭐ | ⭐ | ⭐ | ⭐ |
The "Design" section of the article (see below) goes into more details as for the why.
So what kind of features do our six contestants support? One can consider six categories (here from the most important to the least important):
- shell essentials: features usually found in a classic prompt (path, user, exit codes…), useful in everyday use (jobs, sensors, multiplexer integration…), or generally considered important (themes…).
- version control: Git, Mercurial, etc.
- environments: dynamic configuration detection (virtual env, shell variables, containers…).
- toolsets versions: current version of specific tools (programming languages, build chains, tools…).
- miscellaneous shell features: shell-related features considered less important (network, terminal title, hyperlinks…).
- services: services running permanently, online or on the machine (music, weather…).
Theses categories are delineated with the main use of the terminal in mind:
- Features in the shell essentials category is what you will need the most often, whatever you are doing in your terminal.
- If you are a programmer, you will pay additional attention to the version control and environments categories.
- If you are a developer, the dev context category is also of interest to you.
- If you do system administration, the miscellaneous category may contain some mildly interesting features.
- If you need features in the services category, you probably misunderstood what a command line interface is, or you are looking for a status bar (which a prompt system can be).
My assessment of the overall support of each feature sets is summarized in the following table:
| Prompt | Essentials | Version control | Environments | Toolsets | Misc | Services |
|---|---|---|---|---|---|---|
| Liquid Prompt | 🌟🌟🌟 | 🌟🌟🌟 | 🌟🌟🌟 | ⭐ | ⭐⭐ | _ |
| *ship | ⭐⭐ | ⭐⭐ | 🌟🌟🌟 | 🌟🌟🌟 | ⭐ | _ |
| PowerLevel10k | ⭐⭐ | ⭐ | 🌟🌟🌟 | ⭐⭐ | ⭐⭐ | ⭐ |
| Oh-My-Posh | ⭐ | ⭐⭐ | ⭐ | ⭐⭐ | ⭐ | ⭐⭐ |
| Powerline | ⭐ | ⭐ | ⭐ | _ | ⭐⭐ | 🌟🌟🌟 |
| Pure | ⭐ | ⭐ | _ | _ | _ | _ |
The "Features" section below goes into details about how some prompts support some of those categories.
Each prompt system has an underlying culture, born from its history, that shows through its design.
For instance, Powerline had a huge impact on the adoption of extra characters in "patched" fonts. Liquid Prompt targeted, right from the beginning, features close to the shell itself, along with having an emphasis on the design. On a different side, PowerLevel10k was designed to be as fast as possible. Surprisingly, Starship also started with a promise of being fast, albeit it does not come close to PowerLevel10k (a good example of how languages are overestimated). It does, however, gather a large community, which in turn provides tons of toolsets support. As a counter example, Pure started on the promise to be ascetic on the feature side, and sticked to the idea.
As for the design, the canditate prompt systems can be spread in three categories:
- those arguing that simpler is better (Pure and *ship),
- those loving the classical "chevrons" look (Powerline and Oh-My-Posh),
- those paying extra attention to the design (Liquid Prompt and PowerLevel10k).
The Pure team, for instance, makes a very clear statement that it is "pretty and minimal".
And by pretty, it means "comes with the perfect prompt character" (sic, it is actually ❯)
and uses pastel colors. Its default look is pretty much obviously shared with Starship,
even if it allows for some theme configuration using the chevrons look as well.
In the documentation of this category of design,
not much is said as to why stuff is displayed (or not).
The second category follows more or less the same philosophy, only thinking that pretty is to have a colored background instead of foreground, the use of patched font for nicely separating segments, and to use icons everywhere.
Of course, you will find prompt systems allowing for a certain amount of configuration of either the icons or the colors, allowing to reproduce one or the other style (Starship and Oh-My-Posh both provide themes in both styles, Liquid Prompt and PowerLevel10k have themes mimicking both of them).
The last category, however, goes into more details when it comes to the why it shows things this or that way, and more generally allows for a more various set of themes.
PowerLevel10k goes as far as providing a configuration wizard to build up the theme that you prefer, combining several design features (number of lines, separator character, etc.) However, out of the impressive technical capabilities, the overall design approach is to display whatever is to be displayed as flashy colored segments with icons.
Liquid Prompt provides out-of-the-box themes and has the most diverse set. Some of its themes have no counterpart in the other prompts, and change a lot from the "series of segments" of all the other prompt systems.
One interesting example of how the design approach matters is how Powerline and Liquid Prompt show to the user that they are in a multiplexer session (those are the only two having this feature). Terminal multiplexers are those system allowing to have multiple permanent sessions on a machine, and detach/attach them at will. Most well known are screen and tmux.
Powerline will display a colored segment displaying the number of tmux clients attached to the session. Liquid Prompt has split its support in two different pieces of information: it will first display the number of detached sessions, and secondly color the brackets enclosing the prompt core (user name, host, path) if it is currently within a multiplexer session. The visual clue is subtle, but if you think about it, it makes sense, as it is "around" what changes with the connection. There is no need to use a lot of space to constantly remind the user of this information, which will be constant during a work session.
Another example is how Starship and Liquid Prompt indicate when sudo is active.
Starship will display an icon (of a wizard),
while Liquid Prompt will change the color of the prompt mark,
close to where the user is typing comands, since sudo credentials
may dramatically impact their effect.
The same kind of difference occurs when connecting via ssh:
Starship displays yet another icon, next to the hostname.
Liquid Prompt will display the hostname with its own color.
Both can be configured to show the hostname only if connected through SSH.
Oh-My-Posh shows a segment with an icon, and
PowerLevel10k will show both username and hostname under SSH,
but they do not show if the user have been switched locally, like the others.
The same approach goes for displaying writing rights or X11 support: Liquid Prompt changes the color of an existing character, while other prompts tend to add a new segment/icon.
You might start to see the trend here: most of the prompts have been designed with the idea that some atomic state must be added to the list of states, or not. That is, they will tend to add a new segment (and/or icon) to the list of segments. Liquid Prompt may very well be the only one that has given some thoughts to the idea of maximizing the reuse of visual clues, and purposely locating them.
Essentially, most prompts systems prioritize asking the question "did you know that?" (e.g. "did you know that you have Python version 3.14?") while Liquid Prompt prioritizes saying "you should note that" (e.g. "you should note that it's time to pull").
Of course, a common claim among almost all prompt systems is that a lot of thing are configurable. A user may reorder what is displayed, and completely change the look and feel of their prompt. This shows in the diversity of compatible themes.
Here, Oh-My-Posh has gone into a lot of effort to advertise a very large set of themes. Along with *ship prompts, they use a declarative configuration language that claims to be the simplest way to assemble a new theme.
I see two problems around that idea, that seem to be very well spread among computer scientists, even far out of prompt configuration (think of build systems, for instance):
- the simplicity claim does not scale,
- it introduces too many constraints and limits innovation.
The first problem is quite obvious if you try to interpret a fully charged prompt configuration, for instance this random one from Oh-My-Posh/atomicBit:
<#ffffff>[</>{{ .HEAD }}{{ if .Staging.Changed }}<#00AA00> \u25cf {{ .Staging.String }}</>{{ end }}{{ if .Working.Changed }}<#D75F00> \u25cf {{ .Working.String }}</>{{ end }}<#ffffff>]-</>"
I am not cherry-picking; I picked this one because it is actually simpler than the default. What does it actually do? I am not sure I would really want to put any effort understanding that. However, I can very well see the interest of doing the same as a Shell script, with commonly understood if/then statements, instead of a brackets soup reverse Polish notation.
My guess is that, in Liquid Prompt, this would look like (not tested, just here for giving an idea):
LP_COLOR_CHANGES=$GREEN
LP_COLOR_COMMITS=$MAGENTA
lp_git=""
if _lp_vcs_head_status; then
lp_git+="$lp_vcs_head_status"
fi
if _lp_vcs_unstaged_lines; then
lp_git+="$LP_COLOR_CHANGES ○+$lp_vcs_unstaged_i_lines/-$lp_vcs_unstaged_d_lines"
fi
if _lp_vcs_commits_off_remote; then
lp_git+="$LP_COLOR_COMMITS ○+$lp_vcs_commit_ahead$NO_COL/$LP_COLOR_COMMITS_BEHIND-$lp_vcs_commit_behind$NO_COL"
fi
Note also how the logic of displaying (or not) is decoupled from the coloring scheme. Now, this may not seem simpler to you, but at least you can read it without having a headache, and it seems to me that you can adapt it more easily to a larger set of use-cases, and it has a finer granularity on the information it can display.
Now, just as it is very difficult to design good build systems (which are a mix of declarative and imperative programs), it is a very hard problem to design a prompt configuration system (for the very same reasons). So don't be too hard on the developers, there is no silver bullet.
The second problem shows in the diversity of themes people can produce in practice. The list of themes available for Oh-My-Posh is impressive. There is no doubt that the declarative approach motivates people to make themes. However, when browsing the long list, it is pretty obvious that they all look alike. Do not expect to have very different designs with those prompts, it's all lists of colored segments.
Here, Liquid Prompt shows an interesting difference.
You can reconfigure themes with the classical key=value approach,
but more generally, themes are pure shell scripts arranging the available information.
This allows for all kind of subtleties, most generally displaying any information
in any form, for any combination of states,
which is completely impossible to do efficiently with a declarative approach.
Incidentally, the approach used by Liquid Prompt allows to easily combine configurations (called presets). So that you can use one theme, and then use a preset to change some of its color (for example if you have some color blindness).
The impact of the approach shows in the diversity of themes that Liquid Prompt is proposing. There it is not just about changing colors and icons, but the whole user experience can be impacted. For instance, the GitCrux theme shows the default theme, but adds visual hints about what Git commands may be useful given the state of the current repository. For that theme, Liquid Prompt is more like a data provider, a theme engine that it uses for its own purpose.
One can see some innovation in the DotMatrix theme, where some information is displayed not with icons/segments, but just with some directed spaces. For example, in Dotmatrix, when you are connected through SSH, a space surrounded with left arrows is inserted between the terminal type (i.e. pure text or graphical session) and the user. The same goes for indicating a multiplexer session: a space is shown between the user and the hostname. The theme uses the same idea for version control, and when some commits are waiting to be pushed (spaced arrows to the left —where the server is) or pulled (spaced arrows to the right —were you are).
This kind of design would necessitate a complete refactoring of the theme engine in other prompt systems, but requires only a motivated developer knowing the shell on Liquid Prompt.
Design is good and all, but at the end of the day, software should have the features that matter. You know, actually having something to display.
To get into the details of features, I listed all the features that each prompt system had, and then checked which ones also support them. Then I evaluated the quality of this support:
- no support,
- basic support and design,
- good feature set, but poor ergonomics,
- good feature set and ergonomics.
Results are given in the following table, and thoughts about what that means in the following sections.
In this table, the numbers in cells figure the level of quality of the feature. Popularity is the sum of levels in the row. "Support" lines are the sum of levels in the column, for each category section. Category sections are sorted from top to bottom based on their average popularity. Projects are sorted from left to right, based on their support score in the essentials section.
The following sections will discuss some of the feature sets shown in this table and how the prompt systems compares.
The shell is quite an old piece of software. Old in a good way: it has been tested and upgraded to match a level of quality that allows for efficient work. Moreover, it is quite probable that most of your time is spent working on a few categories of tasks: developer, sysadmin, devops, data analyst, or any variant of those flavors. Whatever your tasks, you would probably benefit from knowing (and using) a "power user" feature set. If you are reading this article this far, chances are that you are comfortable using the shell and either are a power user, or an aspiring one.
The prompt system's primary task is to display some kind of state related to the machine, shell/environment, or directory at hand. The most important states would also be either the ones provided by the shell itself, or the ones that may hinder your work with it (probably the computer state itself). Those features are essentials, and they should have first-class citizenship in the prompt.
In the table above, I separated the machine and shell-related features in two
categories: essentials and the miscellaneous features.
The miscellaneous category hosts the network-related features, because they are
notoriously crippled with all kind of pitfalls.
I also put the "dir stack" feature (the pushd and popd commands)
there, because it is not frequently used among shell users.
This is a pity, because it is a powerful feature.
I also put direnv there.
While this is not a core shell feature (this is external software after all),
it is very close to a shell core feature and I thought it deserved more
than the "dev context" category.
In our table, the prompt systems are sorted by how well they support those essential features. It should be pretty obvious that Liquid Prompt as the best support, by far. The other prompts nicely scale down, with Starship having a good support, albeit with some questionable ergonomics choices (as seen in the "Design" section), followed by Oh-My-Posh and Powerlevel10k, both with average support and overall average ergonomics. Pure has poor support by design, so this cannot be held against it, but if you are a power user rather than a ascetic user, you may have a strong opinion about this choice.
For developer tasks, one feature that is crucial is to know what software context you are currently dealing with. Of course, this has to be split into the support of this or that software. There is two general categories related to that: software that manipulates the current configuration of your session (proper virtual environments), and the current version of any tool related to the task at hand (toolset). If you are playing with containers all day long, you will love those features (once you found a way to install the prompt there).
For the "environments" category, the support is quite sparse among the main competitors (Liquid Prompt, *ship, and PowerLevel10k), with Starship having the best overall support and ergonomics. Oh-My-Posh is a little bit behind, and Powerline almost nowhere. Pure, as usual, decided to not support that kind of stuff.
But the real split is in the "toolset" category, with Pure and Powerline having decided not to support this kind of features, Liquid Prompt supporting two tools only, and *ship, Oh-My-Posh and PowerLevel10k betting on it like hell. Among them, Starship is the clear winner, with an impressive list of supported tools.
However, this category is prone to having a very limited user experience, with each feature being reduced to "just display the icon/version". For most of them (like programming languages), this can easily be understood, since there is not much to warn against anyway. For others (like build systems), I think prompt systems can do better.
Overall, I am not completely convinced that this feature set is really important enough to cripple the prompt with icons and numbers, but since Starship seems to judge it crucial, there is surely some use cases for it out there.
As a side note, one can see that Starship claims to be "minimal" on its homepage, which does not quite match the level of support it has for toolsets… but I digress.
A feature that is constantly discussed by users is the speed of the prompt. That is, the time taken to display it after having ran a command.
Now, you may think that this is a very important feature, and that no compromise should be made in that matter. I have a slightly different point of view.
The shell is a command interface. That is: you type, enter, then look at the result of the command, then think about the next one. Chances are that you almost never frenetically type enter after a command that was very fast to produce its output. You type, you think, you type the next command. You don't need the latency of a first person shooter.
Of course, there is a threshold above which latency of display starts to produce friction. The PowerLevel10k author discussed in great detail what is indistinguishable from no latency, which gives you an idea of the smallest latency you may notice, but not quite what you would actually tolerate in a typical session.
From this point of view, there is a clear winner: PowerLevel10k is incredibly fast. It went to great extents to reduce its latency, and managed some very impressive technical tours de force, like displaying slow prompt elements asynchronously, updating lazily. This also explains for a large part why it supports only Zsh.
I can see the benefit of reducing the friction of having to wait for typing; but I think one often overestimates the interest of ultra-low latency, when the price to pay is that the information of interest may actually not be displayed when you need to think about it.
An interesting fact around latency is the curious claim that Starship is making about it. On their homepage, they claim that Starship is "blazing fast", because it is programmed in Rust, which "brings the best-in-class speed". This does not quite hold up in real-life comparison. Not only is Starship a lot slower than PowerLevel10k, but it is also slower than Liquid Prompt —written in pure shell script— in most simple use cases! Oh-My-Posh —written in Go— does not make the same kind of claim, for instance.
Romkatv explains it in his study:
"Starship is implemented as an external binary, so it has to pay the price of at least one additional fork+exec on every command compared to native zsh prompts. One fork+exec cannot account for the high lag starship exhibits, so what gives? Under the benchmark conditions starship clones 158 times! That's costly."
That may be counter intuitive to most, but the language is far from being the most important aspect of programming.
If you go into sufficiently many details, you can probably always argue that this or that prompt system would be the best for this very specific use case. With the information given in this article, I hope you can decide for yourself. Now, if you would prefer an overall assessment, I think it is clear that there are a couple of prompt systems which fit better a few major use cases.
First, I think it is safe to argue that there is very little interest in choosing Pure, if it's not for signaling that you position yourself as aligned with its narrative (i.e. believe in "one size does fit all", or "I don't really use the shell anyway"). Most of the other contenders have themes reproducing its (absence of) feature set, and even proposing to have the very same style, only supporting more use cases (other version systems, more alerts about the computer's state, etc.)
Similarly, Powerline is probably of not much use out of its core market, which is to produce status lines. And even the other prompts can usually provide much more information for doing so, apart from some specific online services.
Additionally, Spaceship can also safely be set aside, given that it has been superseded by Starship, which supports more features (unless you would need some very specific toolset identification, see the table above).
After much hesitation, I decided to set aside Oh-My-Posh as well. This is not easy, given that it is quite good on almost all of the evaluation criteria I developed in this article, which is a quite an achievement already. But here lies its default: it is only average everywhere.
That leaves us with Liquid Prompt, Starship and PowerLevel10k.
PowerLevel10k is the most popular (as per Github stars metric) and is the obvious choice if you care more about latency than about features. It has an average support of each feature categories, but has worked real hard to provide an ultra-low latency between two commands. I am not sure this is worth the reduced features set and portability, given that I am very rarely annoyed by big latencies when they occur in other prompt systems, but your mileage may vary. It nonetheless has a couple of very modern and innovative design choices, which I very much like, even if I feel that they are more impressive technical sparkles than really useful design anchored in the user experience.
Starship is not far behind in terms of stars, and obviously shines in supporting toolset identification. Whether or not this would be useful to you is a matter of how often you juggle with complex developer tasks. As a research engineer, I constantly juggle with a very diverse set of tasks, so I am more appealed to by systems that cover well the core features of the shell than listing versions, but I guess this can be debated. Anyway, if you require portability to PowerShell, Starship is a safe choice. Also keep in mind that its claims about latency are exaggerated.
While being the oldest of all, Liquid Prompt is also the least known. However, it has the best support of essential features. I would also claim that it has paid more attention to its design, allowing for very dense prompts, for instance. It also has an awesome configurability which has allowed for very original themes, in terms of user experience. It is probably the prompt that will serves the largest set of use cases and users, especially people wanting to learn the shell by experiencing all its features.
This article gave you some opinions based on a snapshot analysis of a market which continues to evolve. As such, it is only a point in time and can very well be made obsolete by a sudden change in the activity of one or the other project.
Along the history of prompt systems, all of them decoupled the gathering of the data and their display. And gathering data is the costliest operation, which gathers all the attention when the runtime needs to be optimized. PowerLevel10k, for instance, completely decoupled the two operations, which now run in parallel coroutines. Its author even implemented a precursor Git status service, which greatly helps speeding up prompts.
Another interesting trend is to decouple the gathering of data into atomic pieces of software, like plugins. Starship would probably not have had its impressive toolset support if it wasn't for its clean and modular codebase.
At the same time, Liquid Prompt put great effort in allowing themes to decide a lot of what and (more importantly) how and when to display, going farther than thinking of themes as mere configurations.
I think those three trends converge to the idea of a prompt service, where the server is responsible of the data gathering and caching, while the client is responsible for articulating this information in a way that is useful for the user (not just displaying it).
The idea has been explored here and there, to my knowledge most notably by Liquid Prompt developers, with projects such as Dolmen's AngelPS1 and Rycieos' MOST. If you like it, the Liquid Prompt maintainer has started a conversation about "theme engines", do not hesitate to join and participate to forging the future of prompt systems.