Get the top HN stories in your inbox every day.
juxtapose
Twirrim
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.
neilv
The "minimal" part is a little funny. Historical minimal shell prompts:
$
#
%
>dijit
here's a tip for people that I stole from PLAN9:
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
sweetgiorni
zsh-histdb achieves something similar. Combined with zsh-autosuggestions it's quite nice.
JimDabell
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:
: ▶
adhesive_wombat
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.
Arch-TK
>struggle using git on the command line and use git status nearly every other command
I think you are conflating two separate things.
I don't care for starship or prompts which show git status information. But, when interacting with git, I do often type git status.
That being said, I don't struggle with git.
Really, when I don't need status information, I don't want the horizontal space taken up with an unnecessarily noisy prompt.
tracker1
Largely of the same mind. I've found starship very useful and have been using it everywhere I can fit a few years now.
JimDabell
> Git information is extremely useful to me.
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?
the_gipsy
It's probably a bell curve and you're only seeing the left side.
happymellon
Yes, having the git project displayed is useful.
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.
tetris11
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
angra_mainyu
I have a tiny prompt I wrote that adds two important bits: git branch w/ status (if in a git repo) and venv (if any).
So it looks like:
me@pop-os 09:19:20 files: 49
~> /path/to/cwd
$
me@pop-os 09:20:14 files: 18
~> ~/dev/work/projects/someproject
[ git ~ feature/some-feature || Add: 0 Mod: 1 Del: 0 Unt: 0 ]
$
me@pop-os 09:20:14 files: 18 (venv: my-venv)
~> ~/dev/work/projects/someproject
[ git ~ feature/some-feature || Add: 0 Mod: 1 Del: 0 Unt: 0 ]
$
pdimitar
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.
JimDabell
> If that makes me "thinking I am clever" then by all means, spend your life believing that. It increases my productivity though.
If it increases your productivity, then it’s the opposite of what I’m talking about.
neilv
I do the same thing with SSH sessions (no hostname if local). Also:
* username if it's not "me"
* indicator if in `screen` or `tmux` session
* `cwd`
* in reverse-video or bold, on terminals that support that, to stand out
All these things have been useful many times.
Most often, which is shells on local laptop, the prompt is only a reverse-video cwd. The extras appear for less-usual situations.
I should add Git info.
mort96
[flagged]
Narushia
My interactive shell experience has substantially improved after installing Starship. :) The other thing was changing from Bash to Fish.
Night_Thastus
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.
I hope others have a better experience than I.
3PS
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.
FeloniousHam
Me too :). I do wish fish could seamlessly convert and run bash script on the fly..
3PS
> I do wish fish could seamlessly convert and run bash scripts on the fly..
It can. With a little help. I use this:
blooalien
Same. The two work so well together. Been happy with both Fish and Starship for a long(ish) while now.
lazypenguin
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.
weebull
Am I the only one who is getting tired of "It's X in rust" type projects? It's making me dislike the community.
Rust is not a user feature, it's an implementation detail.
<cue people telling me I should consider Rust a feature>
farresito
> 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.
gnur
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.
weebull
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.
eviks
<cue at least one complaint of this kind under almost any Rust-related project>
usrbinbash
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".
Twirrim
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.
sebzim4500
What exactly should the takeaway be? Stop making things in Rust because people on HN will complain?
pdimitar
Who is "they"? Do you imagine all Rust devs as a hive mind?
jpambrun
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.
timeon
Stating the technology makes you dislike the community. >.> Why are you on HN?
rowanG077
Well memory safety is a user feature. So "X but in Rust" has merit if X is written in C or C++.
pdimitar
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.
theshrike79
It's a marketing tactic, there is a non-insignificant people who will check out a project just because of Rust.
rgoulter
Starship's an excellent prompt replacement.
I think it goes well with the fish shell: it's much nicer than the default, without requiring customisation.
Narushia
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.
wodenokoto
I’m not sure I understand. Do you have a screenshot shot of something with and without transient prompt that shows the difference?
jackwilsdon
There's a good example in the Oh My Posh documentation: https://ohmyposh.dev/docs/configuration/transient
hiAndrewQuinn
Yes! This is why I pair the two up in https://github.com/hiAndrewQuinn/shell-bling-ubuntu.
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.
dietr1ch
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.
srid
If you use home-manager, installing starship is as simple as adding `programs.starship.enable = true;`.
https://github.com/srid/nixos-config/blob/master/home/starsh...
Incidentally, starship also gives a visual indication of whether you are in the nix shell or not, which is pretty handy when using direnv:
myaccountonhn
I’m probably on the wrong side of history, but I just don’t like how much color there is in modern cli tools. It is distracting
mkl
You may want to set NO_COLOR: https://no-color.org/. A couple of big discussions about it: https://news.ycombinator.com/item?id=30483417, https://news.ycombinator.com/item?id=36098488
konart
Well, in most casees you can configure it and back in all black and white\green if you want to.
Having 8 (or more) colors help when dealing with information though, at least when you need to get a quick result and not just dig into the man pages.
myaccountonhn
I’ve mostly done that, though some apps use one color for foreground and another for background, where it doesn’t work.
lazypenguin
Fair enough but the usefulness of a tool like this is not the colors it's the additional context at the prompt
retrochameleon
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.
Hamuko
I like some colour but some tools take it way too far. As for emoji, the appropriate amount of them in a CLI tool is zero.
ykonstant
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.
chrisan
if the color conveys something meaningful then its good (imo of course)
eviks
is red on error, no color on success (of the last command) also too much?
myaccountonhn
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.
illusive4080
[flagged]
usrbinbash
> "minimal"
Here is what a minimal shell prompt looks like:
$
current-directory@hostname $
daliusd
I still think minimal is appropriate in this case as it shows only what’s relevant in the context.
INTPenis
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.
daliusd
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).
tecoholic
Installed it yesterday and it threw my email and AWS default region on to the prompt. Pretty bad defaults. Promptly removed it.
gkfasdfasdf
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.
notnmeyer
it’s trivial to configure fwiw. with as much info as it is capable of showing it’s a stretch to think it’ll magically know what you want.
tecoholic
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.
kuschkufan
Thank you for your opinion.
joshstrange
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?
wodenokoto
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”
joshstrange
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.
Thank you!
KolenCh
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.
rgoulter
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_gipsy
Two lines is wasteful, but it does look nice that the input is always full width.
Another minimal prompt: https://lib.rs/crates/pista
Get the top HN stories in your inbox every day.
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.