I've been using Starship for quite some time, and it's awesome! Definitely recommend it to anyone who wants a fast, modern, and rich prompt.
Besides the product, the community is pleasantly awesome as well. I've contributed a module to it and the maintainer has done a good job reviewing and testing. Heck, they even have a Discord server for contributors.
I've tried a number of different shell prompt tools over the past few decades. I've disliked them all due to their latency. I don't want to "feel" the delay. They were all in scripting languages, be it native bash, or python or whatever.
I tried out starship about three years ago and it is so fast I don't notice its execution time at all. I switched and haven't looked back.
If your shell is ZSH and you have `setopt autocd` in your .zshrc (though I think this setting is on by default):
export PS1="%~; "
this will result in the prompt: `~; ` where the ~ will change to a path relative to home.
Why do this? Well; it means you can select and paste any line in your history: your prompt becomes part of setting the proper context and is part of the command. Just select the entire line. :D
I think a huge amount of these prompts are just fiddling with things because people think they are clever, not because they are actually useful.
My prompt for years has been:
: ▶
I add the hostname if it’s an SSH session and change ▶ to # if I’m root because those are both important contexts that should be omnipresent, but aside from that, I haven’t felt like I’m missing anything at all. The CWD is in the window / tab title bar, but I never need to look at it because the CWD is always so closely tied to what I am doing in the shell that it’s always top of mind.
Git information is extremely useful to me. I notice colleagues who don't have that tend to struggle using git on the command line and use git status nearly every other command (much as I tend to do when I'm remoting into a shell with a plain prompt).
Python venvs are useful too if you have a shell for running the program and other shells that just happen to be within that directory.
I could see the case for that if it were accurate. But every implementation I’ve seen doesn’t give you accurate Git information. It gives you the status of the repo as it was when you last ran a command. If you are working on the repo in a separate editor window, then the Git information in your prompt is usually incorrect. Incorrect information is worse than no information. Besides which, your editor normally provides this information as you are working on it. Why does outdated Git information belong in a prompt when there are more convenient places to get the correct information?
I can honestly say that has never once been a problem I have had, and I've had git information in the prompt for over 10 years.
Also how is "enter" less convenient than literally any other command that you'd still have to type and run to get up-to-date information in a command line?
> I can honestly say that has never once been a problem I have had, and I've had git information in the prompt for over 10 years.
What do you mean exactly?
Are you saying it doesn’t get out of date? i.e. you never change the state of the repository outside of your terminal session? I don’t think that’s reflective of how most people work.
Are you saying that it gets out of date but that doesn’t matter? If that’s the case, then it’s a strong hint that the information isn’t as useful as you assume. What’s the point in constantly, repeatedly showing incorrect information?
Are you saying that you work around the problem by hitting enter whenever you want an update? Then aren’t you doing the same thing as your colleagues who you mention struggle with Git? Hitting enter in your case is essentially a shortcut for running `git status` over and over, except you are doing it with literally every command you run instead of only when you need to.
> Also how is "enter" less convenient than literally any other command that you'd still have to type and run to get up-to-date information in a command line?
The issue is the space and attention used by repeatedly showing outdated Git information. Space and attention are at a premium in a terminal window; you can’t just dump all the information available to you in there for free.
> Are you saying it doesn’t get out of date? i.e. you never change the state of the repository outside of your terminal session? I don’t think that’s reflective of how most people work.
That's what I do, I use git directly for trivial stuff and lazygit for more complex stuff, both inside the terminal.
> Space and attention are at a premium in a terminal window; you can’t just dump all the information available to you in there for free.
That's true. I've tried "absolutely nothing except %", "very long and fancy prompts" and the current directory (often aliased), the current git branch and % is what works well for me.
To a lesser extent, I've done a few Java version migrations so it can be useful for the Java version to be printed so it's obvious if I've got the wrong JDK enabled. Python fell under this, but I don't think I'll have to worry about having one project be Python 2 while the others are 3 anymore.
I like this approach. I tried using starship.rs but I have to say it does far more than I want it to and makes me feel like I'm not in control of my shell (e.g. it pulls a schema via an URL without any knowledge from me that it does so).
As a result, I've written my own small and concise PS1 which covers all my use cases:
## Add this to ~/.bashrc
force_color_prompt=yes
## show: user+hostname (if ssh), conda, venv, guix, and git
function prompt_command {
## styles and symbols
local RESET='\[\033[0m\]' ; local BLD_GRN='\[\033[1;32m\]';
local BLD_YLW='\[\033[1;33m\]'; local BLD_PPL='\[\033[1;35m\]';
local BLD_CYN='\[\033[1;36m\]'; local BLD_WHT='\[\033[1;37m\]'
local ITL_YLW='\[\033[3;33m\]'; local SEP='⋮'
PROMPT_DIRTRIM=2
export PS1=""
if [ -n "$SSH_CONNECTION" ]; then
PS1=${PS1}${BLD_CYN}'\u'${BLD_YLW}'@'${BLD_GRN}'\h'${RESET}
fi
if [ -n "$CONDA_DEFAULT_ENV" ]; then
PS1=${PS1}${SEP}${ITL_YLW}${CONDA_DEFAULT_ENV}${RESET}
fi
if [ -n "$VIRTUAL_ENV" ]; then
PS1=${PS1}${SEP}${BLD_WHT}${VIRTUAL_ENV##*/}${RESET}
fi
if [ -n "$GUIX_ENVIRONMENT" ]; then
PS1=${PS1}${SEP}${BLD_GRN}'GUIX'${RESET}
fi
if [ -e .git ]; then
PS1=${PS1}${SEP}${BLD_PPL}$(git branch --show-current)${RESET}
fi
PS1=${PS1}${SEP}${BLD_GRN}'\w' # short directory
PS1=${PS1}${BLD_YLW}'▶ '${RESET}
}
export PROMPT_COMMAND=prompt_command
The GIT status prompt is immensely useful. Not as useful, but still occasionally useful, are the prompts for language / tool versions. And how much time did the last command take. I make a regular use of that when I don't need sub-second timings.
If that makes me "thinking I am clever" then by all means, spend your life believing that. It increases my productivity though.
I love Fish, but I cannot for the life of me to get Starship working well.
Trying to get it working on WSL (Ubuntu 20.04 and Centos) as well as MSYS just wasn't happening. On the few occasions I did get it working, it was unbearably slow. Simple commands would have sometimes half a second of delay. I could time what was causing the slowdown and disable some of it, but by the time I got it bearable I had disabled basically all of Starship. Then there were font-related issues on top. Ugh.
Chiming in as another fish+starship user. It's hard to imagine using anything else now; I get just about every feature I would ever want out of my shell with essentially zero configuration, which makes it easy to replicate my setup across a ton of heterogeneous devices and operating systems.
I discovered starship when I started using kubernetes at work. Previously I relied on standard bash-isms for path, hostname, etc. but knowing what context and namespace I'm in before I execute a command is quite convenient. I'm normally not one to "customize" my CLI experience at all but this was a nice addition to the toolbox. Documentation is good, customizable, reliable and has support for a lot of things. Would recommend.
> Rust is not a user feature, it's an implementation detail
Sure, but keep in mind that in the case of open source software plenty of people will choose software written in their favorite language so that they can potentially contribute to it. Or simply because they feel more connected to something that is written in their favorite language. So I don't think it's completely irrelevant.
It might not be a feature, but it is a selling point. It conveys that it was written relatively recently, is more likely to support modern features in the shell, runs reasonably fast and is reasonably portable.
If it was written in JS or python I'd already start worrying about what package manager to install it with in which environment, installing it globally is an anti pattern but symlinking it to .local/bin might complicate it.
So IMHO, the language something is written in is not just an implementation detail, it informs me in how well it will perform.
It's a prompt. Writing anything for that purpose is code gardening, but hey it's in rust so I'm supposed to be excited?
That, in essence is the problem "X in rust" normally means "I've written something of low value IN RUST. Gimmee upvotes". Come back when the project is interesting regardless of the language.
The fact that this happens should be food for thought for part of the rust community. Because the way I see it, if they keep this up, a few years from now, they could, other than some obscure linux kernel modules almost noone uses and a good grep-alternative, be well along what I lovingly call the "Haskell Route".
Almost every single project that makes it to the front page of HN tells you as part of the opening sentences what language it's in. For a good while it was "<thing>, (re)written in Go". There's nothing special or unique in the rust community about this, it's just what people in tech do.
The type of complaining you're doing is also nothing new, because exactly the same occurs under those posts when it's the language de jour. A few years ago when it was all about Go, you could look in the HN comments and see people complaining exactly the same way about Go and the Go community.
But it's an interesting observation, don't you think? Why is it that just by adding "... in Rust" you can almost guarantee that people will roll their eyes and think "oh, not another one".
Other languages do not carry such stigma, why does Rust have such reputation?
Completely guessing, but the thought comes to mind that Rust was (still is? I don't keep up these days) portrayed as The C Killer. So to specify "written in Rust" was to imply "I wrote something low-level without C/C++" or "I rewrote Popular C Tool in Rust" in the name of memory safety.
This is all wild speculation on my part, so please take it with a large grain of salt. I welcome alternative explanations or experiences.
> Completely guessing, but the thought comes to mind that Rust was (still is? I don't keep up these days) portrayed as The C Killer. So to specify "written in Rust" was to imply "I wrote something low-level without C/C++" or "I rewrote Popular C Tool in Rust" in the name of memory safety.
As the OP, this is a big part of it. Rust might be a great language, but people announcing they rewrote grep (for example) in rust doesn't mean they've done anything special. The rust language team did something special. The person making the announcement just took somebody else's idea and reimplemented it for very little reason.
Great! You learnt enough to reinvent the wheel. Now do something useful.
I still don't see your original point. Sounds like you have an axe to grind. I don't see anything negative in saying "written in Rust" or "written in OCaml" or "written in Haskell" or anything else.
Using a particular language signals a certain subset of qualities and broadcasting those helps people filter what they are interested in.
What reasons might those be? I am not familiar with Haskell's history.
Are you saying that Haskell never got wide adoption because its advocates were too loud?
Even if you claim that I'll not believe it. Haskell is legitimately difficult for many annoying reasons, not least of which are the endless compiler variants.
> I would say it’s because the Haskell community is too arrogant and pretentious.
That by itself is only a cause. What's the effect, what's the symptom of this attitude, what are the practical observable results? Gatekeeping? Rude forum responses? (I know OCaml partially suffered from that and they can be fairly elitistic; when you ask something fairly normal nowadays like "what's the preferred package manager?" or "how do you build a project?" is sometimes met with smartass responses like "what's a project?")
> I love the language and worked with it professionally for over a year, but I can’t stand everything around the developer experience and community.
Sums up my experience with several development communities, yep. I can relate.
> Rust is a breath of fresh air.
I feel the same, the community is extremely pragmatic. I've met a few a-holes but they were a very, very rare exception. 99% of everyone I interacted with was just like me: they were looking how to get the job done AND write idiomatic and efficient code.
It's strange, because many, many times I've heard newcomers say that the Haskell community is the most friendly and welcoming that they have interacted with. By this point I don't have any better hypothesis than that different people prefer different sorts of community. I also think it's unfortunate if someone stops using a language they love because of the community. Ideally a programming language would have multiple communities so everyone can find one that works for them. Perhaps niche language are too niche for that possibility, though.
> I also think it's unfortunate if someone stops using a language they love because of the community.
This really depends. I don't care about some abstract notion of a community BUT if I can't get basic stuff done because documentation is not good and the official forum responses are not helpful then yes, I absolutely will abandon the language.
To this day, languages differ a lot. I.e. in Elixir and Rust I can just add dependencies to a file (Rust even allows you to add the dep via a CLI command) and then reference it in your code a minute later, issue a command and your project is compiled and runs and you see the result.
Now ask me how much time I spent fiddling with OCaml's `dune` and `esy` which are a project manager and a dependency manager respectively. Took me an entire weekend to get one simple code to compile with a singular CLI command, and then run it. And community was not helpful: "check the docs", which I did 15 times probably over the course of that same weekend.
To go back to your point, friendly / welcoming community is just a bonus. The community has to be helpful above everything else. Some people are noobs. Some people like myself are senior BUT are unwilling to start over and are just looking for "how to do X and Y without spending a full day?". Some people are trying to make a presentation to advocate for the technology on an internal meeting. Examples abound.
I am not an experienced moderator (nor I ever want to be) but I've witnessed significant differences in how various programming language (or just a framework) communities act, and how helpful they are. It absolutely isn't identical or even close. Some are downright off-putting.
Finally, I make no claims about Haskell in any way except only one thing: when I saw its huge combinatorial explosion of different compilers, I gave up on the spot. Give me 2-3 options and leave the rest to the enthusiasts.
Totally agreed with you there. I hope Haskell's community is generally friendly and welcoming, but I guess it isn't always that way.
In case you're interested into how Haskell handles some of the specifics you brought up:
> in Elixir and Rust I can just add dependencies to a file (Rust even allows you to add the dep via a CLI command) and then reference it in your code a minute later, issue a command and your project is compiled and runs and you see the result
This is also true of Haskell using Cabal. Cabal has some rough edges. Perhaps it's not as ergonomic as the Elixir or Rust equivalents (I've never used them) but you can at least do that.
> when I saw its huge combinatorial explosion of different compilers, I gave up on the spot. Give me 2-3 options and leave the rest to the enthusiasts.
This issue has been resolved with the introduction of the GHC2021 language edition. Just use that. No need for any other language extensions as a non-expert, except maybe in very special cases.
(By the way, there was never a combinatorial explosion of compilers. Almost all language extensions simply remove restrictions. But I understand how people could interpret it that way, and GHC2021 is a very simple way of resolving the misunderstanding.)
I never saw any drama. People have broadcasted that they rewrite stuff in Rust, yes, and that seems to have triggered an exaggerated annoyance response in many.
I honestly have no clue and will only speculate. The people criticizing the "rewrite it in Rust" or "written in Rust" monikers always came across as grumpy curmudgeons to me. I never saw an actual good technical criticism.
Also they might have made the mistake of judging a very big and heterogenous community by a few zealot loudmouths (and every community has those).
Informed and objective people shouldn't judge like that but I think it reinforces a preconceived notion that they already have.
The human brain can betray us like that. If you already dislike something, practically every criticism towards it, no matter how small, makes you immediately go: "A-ha! This thing is bad! I knew it!"
I like that go and rust binaries are statically linked. This means that I can build an environment I like using these and bring them almost everywhere, wsl, Mac, Ubuntu, red hat, etc. For me, this is the feature of rust/go.
It's not only though I don't understand why is this getting you "tired".
Rust has memory safety built in (unless one goes VERY out of their way to nullify it) which to many, myself included, is a selling point. F.ex. I wouldn't be interested in the userland tools rewrite if they weren't in Rust.
> Rust is not a user feature, it's an implementation detail.
It is that, yes, but not only that. Again, memory safety. And as another poster pointed out -- statically linked binaries. That helps a lot with certain deployments.
Also consider that HN might not be the place for you if mentioning implementation details are ticking you off. That's more or less how this forum started in the first place: people discussing implementation details.
> Rust is not a user feature, it's an implementation detail.
Rust is the new C. It communicates that something is fast, but also secure, and new or a modern reimplementation of something old. So, in that sense, is it a user feature because it has established itself in a way that tells the user some important details.
Am I the only one who is getting tired of comments complaining about people put “written in Rust” in the title? Lately every post having “written in Rust” has a comment like this.
If you don’t care, ignore it. Why should it bother you so much?
"X in Rust" to me mean that I won't have to fiddle with it when installing it and it'll work out of the box. This isn't unique to Rust, Go does this very well too. It'll also be reasonably fast, not just because of the language, but because the community likes performance. For example, a few years ago I tried the tldr command. It was in Node.js and unbearably slow. There was a Rust implementation, tealdeer, that was way faster.
Switching to Starship was actually what inspired me to also switch from Bash to Fish. Purely because of the transient prompt feature, which is not supported for Bash.
With the transient prompt, you can have things like Git or Kubernetes status on your “main prompt”, but without always printing them in the terminal for the commands you ran previously. It keeps the history much cleaner, and therefore more pleasant to scroll back up. I've also configured it to print the time when the commands were executed to the start of the lines.
These context clues are especially important for newcomers to the command line. A CLI newbie who sticks with it might eventually progress to the point where they decide to ditch Starship, or to ditch fish, or to ditch both, but until they get to that point, the solid defaults and OOTB features of these two have a lot going for them. Meanwhile sticking someone in a '$ ' with no coloring, no autocompletion, and no real clues in the terminal itself is more likely to lead to them just giving up entirely.
Maybe it can turn into the default prompt as a library dependency after the Rust rewrite, but the rust rewrite needs to rollout before thinking too far ahead.
When everything is one big screen full of white text, I find it very difficult to visually parse out, separate, and focus on information. Colors help guide your eyes and provide context. They can certainly be overused, however.
Why? I don't think emoji are necessary, but they are just Unicode characters; the only objection I can think of is that they are "too playful", but if our OSS CLI tools, written as a labor of love in our spare time, have to be "serious", we are utterly fucked. Unix hacking has never worn suits and ties.
Unless we are talking about unicode support. Indeed, the software should make a basic inquiry to see if the shell/terminal emulator supports unicode and fall back to ASCII if not. But there is a difference between "I don't support unicode" and "my unicode support is broken": the latter needs fixing, and emoji are actually a good test case to see if you really support unicode.
A little bit, as I find that it can make me lose my trail of thought. Red errors for LSP or because something is wrong in the executed command is great though.
Here is another one which only uses the shells own facilities:
current-directory@hostname $
Running a complex piece of software every time the shell needs to display it's prompt, is not "minimal", regardless of how fast and well written said piece of software is.
You're missing the point. It runs every time you show the prompt. Anything that does that is not minimal and it increases the risk of failure.
Some things that you use regularly should be kept as minimal and as stable as possible. To me that includes the shell prompt, editor, browser for example.
I am cli/vim guy - that’s my daily tools. Starship is very stable and it is useful for me. The only problem I have experienced is with custom extension I wrote myself (problem was slowness not stability).
Please explain how this "uses my own argument against me", when my argument is that "minimal" prompt doesn't involve calling an external program to build the prompt? Both "$ " and "" can be built by the shell itself.
Heh oh my bad, I didn't realise you have the privilege of gatekeeping what "minimal" means ;)
I see one dictionary definition is "the least possible". Seems like the least possible prompt is no prompt at all, but it's really just a matter of opinion ;)
I had a similar reaction to the out of the box config. However after spending a little bit of time with the doc, I turned off all the useless stuff like my docker version and but left stuff like git branch, status, exit code, etc.
My problem is not that it didn’t do what I want, just that it seems to work in a “opt in to everything by default” which was overwhelming. I prefer things that without config don’t do anything or do the bare minimum and then lets me slowly add to it.
I spend so little time relatively on my own machine’s terminal and even when I do I don’t want it to be totally different from the boxes I SSH into every day. That context switch would be frustrating. Nor do I have the desire to push for something like this to be installed on our fleet of servers.
Do the people who use this (along with terminal emulators that require you install things on the host to get the full power) just not use other machines and/or install stuff like this on them? Just seems odd to me personally but I’m interested in how others use it. Do you only use your own computer/terminal so it’s not an issue?
I suppose I “just don’t use other machines” and when I do, they suck and mine rocks, which I consider a lot better than “both sucks, but I am used to it”
Totally understandable. I my computer is highly configured for “me” which means I feel lost if I sit down at someone else’s computer. That said, I spend 90%+ of my time in a terminal SSH’d to other box. If it was closer to 50-50 I’d be more interested but improving <10% and the added context switch isn’t worth it for me personally.
If you want to, you can invest time in automating this so that you can feel at home at every boxes.
Surely it is some work to ensure your user environment are all the same across different machines. But it is also liberating as you are no longer limited to choose the few common features available everywhere.
If it's a machine that you're going to be working on a lot, you might as well have good tools installed. (And if it's a machine where stuff like starship would be bloat, then it's probably not something people should be SSHing into frequently).
The main reason I use fish shell is for the autocompletion feature it offers out of the box. If it had been an option back in the day, I would have tried something like starship
It's quite portable (didn't test on Windows though); ~170 lines of Go; no dependencies outside of stdlib; calls no external commands; supports SSH, git, Docker, nix, and virtualenv; extremely simple to hack on.
`custom` spawns a child process of your shell, so it's probably being slowed down by a slow shell init script.
If the custom script you're running doesn't require your full shell customization to work, you can provide a custom shell command [0], passing an argument to not use your shell config.
For instance: `fish --no-config` or `bash --noprofile --norc`
So now I need to install nerd font and this software on all clients' machines and VMs and whatnot. Asking IT departments for permission and waiting for compliance check.
Or should I do it only on toy machines, risking different experience between them and production.
No, thanks. Plain bash will suffice. Just like it did for so many years.
I tried this couple of times and once a few days ago and wasn’t impressed. Coming from powerlevel10k it seems more limiting and not really faster. Has anyone think starship is better than powerlevel10k and how?
Maybe read through the documentation and try it out. It has very robust configuration options, many pre-built modules that are ready to include in your prompt, for example, one that prints git info for the current location if it's a repository.
So yes, it is kind of a competitor to p10k, but not zsh. It's just the prompt, and it just focuses on being a very good prompt tool.
Have you tried writing a PS1 which shows all the info that's demonstrated on the linked page?
I have. It's a decent chunk of work. It's a whole lot more work to do it well. Did you remember to handle the situation where the git repo is so gigantic that running `git status` takes half a minute? Or the case where there is a .git folder somewhere but permissions are wrong or it crosses a mount barrier so `git status` prints a page of text to stderr? Does the way you're finding the current branch handle the case where HEAD doesn't point to a branch?
The only way your prompt "already does" this stuff is if you've spent a whole lot of time configuring it and tuning it, or if you're already using something like oh-my-zsh. And if you're already using something like oh-my-zsh, well, starship is just a competitor to (the prompt portion of) that.
People want something easy to use with good defaults. If that wasn't the case, shells wouldn't have a hundreds of plugins dedicated to customizing the prompt.
It's simpler to configure and extend, and also more likely gets support for more exotic information-sources. It's a dedicated tool for this specific job, so following the "Unix-philosophy". And probably more optimized for edge cases like big git-repos and stuff. And you can easily switch shells.
I have a bookmark-folder of release-sites and changelogs I visit ever some months. Though, they are on github, which has a Newsfeed, so at some point I switch to a feedreader or mail-forwarder to have this more under control. But I'm still searching for something good.
If you find that wasteful, you can use the “transient prompt” feature to only print the full prompt to the current line, but keep the command history on one line per command in the terminal.
In contrast to the minimalist philosophy, I want to have as much visual information about the active state of my session as possible. So many stories of deleted files and databases, botched git actions and server crashes due to admins/devs forgetting which folder/host they are on, or which user they are logged in as, or whether the previous command failed or not.
Personally, I find the extra blank line to be a useful visual separator between lines of output. Particularly useful when running commands with lots of output or 'cat'-ing files or logs.
I agree with the latter point. But I use xonsh as the shell and that has a prompt which can go on the last line of the terminal and does not get repeated each time, so when you scroll back you don't all the information each time.
I use that for starship information and the prompt is just the return code p[lus a character.
lot of information that'd be nicer to have at a higher level than the prompt, like the tmux or screen status bar. Be even better if a "prompt" like this could set a variable using ANSI escapes that various terminal emulators could display.
It’s too bad this requires a Nerd font to be installed according to the landing page. I just don’t think that belongs in a terminal emulator and it should be optional
The homepage is somewhat misleading, you can use it without Nerd Fonts and there's actually a preset config listed for it mentioned on the Presets page [0] with the note:
> This preset will become the default preset in a future release of starship
It also links to an open issue on the GH repo about it [1] (although that issue is 2 years old and doesn't seem to be top priority.)
Besides the product, the community is pleasantly awesome as well. I've contributed a module to it and the maintainer has done a good job reviewing and testing. Heck, they even have a Discord server for contributors.