[HN Gopher] Starship: The minimal, fast, and customizable prompt...
___________________________________________________________________
Starship: The minimal, fast, and customizable prompt for any shell
Author : benoitg
Score : 350 points
Date : 2025-06-24 11:11 UTC (11 hours ago)
(HTM) web link (starship.rs)
(TXT) w3m dump (starship.rs)
| voidUpdate wrote:
| Does the speed of your shell matter? Surely the speed of the
| programs that you're running through your shell matter more. I've
| never been let down by how fast bash can tell a program to start
| running
|
| EDIT: oh, i misunderstood, its just the prompt at the start of
| your shell... I dont think ive ever been annoyed at how fast that
| renders either
| mlenz wrote:
| In this case it's about the actual startup time of your shell.
| When launching a new terminal, starship always need to perform
| its initialization. If it were slow, I wouldn't use it because
| waiting seconds before being able to input anything is kind of
| annoying. That's what they're referring to.
| danpalmer wrote:
| Some people like to put, for example, their current git branch
| in the prompt. To get that means at least naively, running a
| git command on every single line the prompt renders on. Git is
| fast, but it's easy to add a bunch of these and suddenly your
| prompt takes 100ms to render. Hit enter a few times and you'll
| immediately notice lag. For that reason, doing this fast does
| make a real difference.
|
| Of course the fastest thing is to just not stuff your prompt
| full of detail.
| blueflow wrote:
| If you do not have any subshells or command substitutions in
| your PS1, then you also save alot of time on platforms like
| WSL, where forks are expensive.
| account42 wrote:
| > Git is fast, but it's easy to add a bunch of these and
| suddenly your prompt takes 100ms to render.
|
| Or maybe many seconds if you have network drives over a slow
| VPN connection - not working on network drives, just having
| them connected. Fun to diagnose when you need to get urgent
| work done while traveling.
| WhyNotHugo wrote:
| Even 'git status' gets slow on large repositories (or slow
| hosts).
|
| git status takes 643ms for github.com/rust-lang/rust
| goriv wrote:
| I used to use spaceship prompt before this, and it would often
| take 5s to open up a new terminal and wait for the prompt to
| load, starship is always instant (like a prompt should be).
| Twirrim wrote:
| Every single time your prompt appears, your shell is doing
| something. I've tried using various prompt customising things
| in the past, but they've almost all been written in shell, and
| always been palpably slow. To the degree that I've found it
| irritating and stopped using them.
|
| Starship is the first one that hasn't irritated me, in no small
| part because it's lightning fast, typically only couple of
| milliseconds to gather and render the prompt.
|
| This is the first time I've been able to stick with one.
| WhyNotHugo wrote:
| I've tried tools in this space which add hundreds of
| milliseconds to a shell's start-up time. That's easily
| noticeable, especially when the system is under heavy load.
| JimDabell wrote:
| I don't understand why they market this as "minimal". It's got
| loads of features, and every time I see somebody use it they have
| a huge prompt with loads of bells and whistles.
|
| My shell prompt is: : >
|
| You don't need an entire shell prompt customisation framework to
| be minimal.
| Cthulhu_ wrote:
| Yeah this isn't minimal, this is maximalism - more information,
| more characters. They should just embrace being a maximalist
| prompt.
| slightwinder wrote:
| Compared to other shells and prompts, the configuration is
| really straightforward and minimal if you want something mildly
| complex.
| Brajeshwar wrote:
| Mine is an even thinner arrow.
|
| # clean, simple, minimal PROMPT='%{%F{red}%}%~
| %{%F{yellow}%}% > %{%F{reset_color}%}%'
| Twirrim wrote:
| 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"""
| faizmokh wrote:
| Tried it. Not a fan. I find it unnecessarily fancy.
| Asraelite wrote:
| Then customize it not to be. Are you criticizing it for having
| too many configuration options?
| account42 wrote:
| For a non-fancy prompt, setting PS1 is enough - no need to
| install anything.
| Quitschquat wrote:
| Too much bloat. If I want minimal, I'll use a PS1 with 4
| characters in it
| maztaim wrote:
| I found https://ohmyposh.dev/ works for me. There's something
| about transient prompts that (at the time?) was a problem for
| starship. There are several other alternatives I've tried with
| meh results.
| Cthulhu_ wrote:
| I've used Powerlevel10k for ages
| (https://github.com/romkatv/powerlevel10k), but it seems it's
| no longer actively developed / maintained. I think it's a lot
| cleaner, how I have it set up right now it shows some
| information like timestamp, Ruby versions, command runtime etc
| on the right side, whereas Starship shows it right at the
| prompt.
| maztaim wrote:
| Same here, that's what prompted my search. I felt I could get
| closest with oh-my-posh.
| iaresee wrote:
| That was the same thing that drove me to find an
| alternative and I also landed on ohmyposh specifically
| because starship lacked the transient prompt.
| fwip wrote:
| I'm not 100% sure what a transient prompt is, but it
| looks like Starship now might have support for them.
|
| [right prompt docs] https://starship.rs/advanced-
| config/#enable-right-prompt [transient prompt docs]
| https://starship.rs/advanced-config/#transientprompt-and-
| tra...
| taude wrote:
| oh, wow, didn't realize powerlevel10k was no longer
| maintained. that's a bummer. I liked it better than Starship
| last time I yak-shaved my local cli workflow.
| albybisy wrote:
| i prefer powerlevel10K
| b0a04gl wrote:
| every time your shell takes 100ms to render git status that you
| didn't even need, you're paying invisible tax on flow. terminals
| should be reactive memory tools, not passive decoration. we
| optimize for code runtime but not for our own typing latency
| Twirrim wrote:
| 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.
| Night_Thastus wrote:
| Depends a lot on the system. I tried using it on Windows via
| MSYS2, and it seems like some Windows overhead (maybe process
| startup?) was causing Starship to slow it all down to a
| crawl. Disabling a few of the addons helped but didn't fix
| it. In the end I stopped using it.
| lukeschlather wrote:
| I don't know if Windows can be helped. It may be antivirus
| but I feel like 50th percentile load time is at least a
| second and there's nothing to be done about it. git just
| hangs sometimes on git show/git diff. I have to kill the
| terminal.
| WorldMaker wrote:
| My experience of Starship on Windows has been great. I'm
| using the Windows native builds of both Starship and git
| (both installed/updated via winget these days) in
| PowerShell.
|
| I try to avoid emulation layers like MSYS2, as much as
| I'm able.
|
| Also, yes, if git hangs on git show/git diff that sounds
| like an antivirus problem or a dying hard drive or the
| first one causing the other one.
| Twirrim wrote:
| Or just a really big git repo. Starship includes a
| timings command, on linux (with an annoying antivirus
| meddling) this is what I see against one directory:
| git_status - 6ms - "[!?] " directory -
| 4ms - "<redacted> " python - 3ms -
| "via v3.12.9 (.venv) " character - <1ms -
| " " git_branch - <1ms - "on main "
| hostname - <1ms - "<redacted> in "
|
| If I go in to my checked out version of the linux kernel,
| probably the biggest git project I've got kicking around:
| git_status - 115ms - "" directory - 4ms
| - "linux " character - <1ms - " "
| git_branch - <1ms - "on master " hostname
| - <1ms - "<redacted> in "
|
| That's typically the worst I see it.
| WorldMaker wrote:
| I appreciate Starship also has configurable limits on
| those timings, too. I've almost never seen Starship hang
| for very long, as it will just drop the thing that is
| slow. I sometimes but rarely (usually just starting a new
| shell, but sometimes if compiling in another
| window/terminal) see the "[WARN] Executing command git
| timed out" error and the git_status won't display until
| the next prompt and that is usually fine.
| pxc wrote:
| Windows' filesystem performance for tools that expect Unix
| is abysmal, and it gets drastically worse in most corporate
| environments because endpoint security software hooks into
| the filesystem drivers to instrument all file access.
|
| Git-aware prompts can't be recommended on Windows, imo.
| bregma wrote:
| 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.
| dminik wrote:
| There's a thousand milliseconds in a second. If your VSCode
| is taking +10 seconds to display a single character, it might
| be time to upgrade from your Commodore 64.
| falcor84 wrote:
| Or to switch from VSCode to SpeedScript
| gapan wrote:
| Well, actually, the Commodore 64 is a lot faster with
| respect to input latency than any modern machine.
| OptionX wrote:
| _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.
| naniwaduni wrote:
| 100 ms is an incredibly long time even for humans.
| infogulch wrote:
| 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.
| gobblegobble2 wrote:
| 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
| perrygeo wrote:
| 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!
| account42 wrote:
| > we optimize for code runtime but not for our own typing
| latency
|
| Don't the layers of frameworks mean that the opposite is true.
| eevahr wrote:
| My personal favourite: PS1="%~ $ "
| blueflow wrote:
| I'm assuming that this is a zsh prompt string.
| eevahr wrote:
| Yes, bash would be: PS1='\w \$ '
| hiAndrewQuinn wrote:
| I like maximalist prompts, and indeed Starship is what Shell
| Bling Ubuntu [1] installs on a new dev machine. But they're not
| everyone's cup of tea.
|
| If I wanted to recommend to someone the min-maxed, highest
| density thing they could add to their prompt, it would simply be
| the time your current prompt appeared + the amount of time the
| last command you ran took.
|
| These two pieces of information together make it very easy for
| you (or your local sysadmin (or an LLM looking over your digital
| shoulder)) to piece together a log of exactly what happened when.
| This kind of psuedo-non-repudiation can be invaluable for
| debugging sessions when you least expect it.
|
| This was a tip I distilled from Michael W. Lucas's _Networking
| for System Administrators_ a few years ago, which remains my
| preferred recommendation for any developers looking to learn just
| enough about networking to not feel totally lost when talking to
| an actual network engineer.
|
| Bonus nerd points if you measure time in seconds since the UNIX
| epoch. Very easy and fast to run time delta calculations if you
| do that: [0 1719242840] $ echo "foo" [0
| 1719242905] $ echo "fell asleep before hitting enter" && sleep 5
| [5 1719242910] $
|
| [1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntu
| skydhash wrote:
| 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.
| hiAndrewQuinn wrote:
| I like stuffing everything which might be important to the
| context window in there, personally. Saving 50ms on the
| prompt load sure beats a false negative when something goes
| wrong because I don't even think to ask whether I have the
| wrong Node version installed or something.
| bayindirh wrote:
| When starting to work on something, I generally do a sanity
| check to see that the fundamentals are there and correct
| versions, then throw that part of the context out of mind,
| knowing that I stand on firm ground.
|
| I found out that with this verify-and-forget step, I work
| much more efficiently.
|
| As a result, my workflow becomes independent of the machine
| I work on, because I become the tool, not my setup. After
| that point, only having a "$" at the beginning of the line
| is enough.
|
| Of course everyone have their own choices, and YMMV.
| bredren wrote:
| Yes. I show the python or node version of currently active
| venv and venv name.
|
| Also, I somehow worked in special characters for Python and
| other things that get screwed up if I don't have the right
| nerd font installed on the system.
| JimDabell wrote:
| How often are you switching these things that you need
| their values in sight at all times though?
|
| Even for cases where I need to use old versions, I don't
| need a reminder of that every time I run a command.
| bredren wrote:
| All of the time. Often I'm working with 3-4 different
| project contexts simultaneously.
|
| It isn't that useful but I do glance it when I'm working
| on dependencies and to ensure the context between a
| terminal session and pycharm's interpreter match.
|
| The information doesn't cloud the prompt for me though,
| as it is right justified and I don't really think about
| time to load, as the machines are relatively recent Apple
| Silicon.
| acedTrex wrote:
| You don't need to know what branch you're on before running
| commands? I cant tell you the number of times ive been on the
| wrong branch executing stuff.
| zikduruqe wrote:
| For me the AWS integration is nice. That way I know what
| account I'm on, and what region among my dozens of windows.
|
| For example: .../.config master on
| AWS_Prod (use2)
|
| starship.toml: [aws] format = 'on
| [($profile )(\($region\) )]($style)' style = 'bold
| #B23D2F' symbol = " " <- cloud symbol
| [aws.region_aliases] us-east-1 = 'use1' us-
| east-2 = 'use2'
| acedTrex wrote:
| Oh ya, for work the kubeconfig integration is absolutely
| essential, i bounce between local clusters and shared
| nonprod clusters all the time and while its not an outage
| to break the nonprods its going to annoy a lot of people
| so its nice to know which one is active.
| alganet wrote:
| I literally use just PS1='$ '.
|
| `git status` to know git stuff. `pwd` for the current
| working directory, etc
|
| I also don't use aliases like `gs` or `..`
|
| One good thing about having a very minimal setup is that
| you feel at home anywhere.
|
| It wasn't always like this. I used many, many prompts and
| shell tools over the decades. The only tool that stood the
| test of time is tmux.
| horsawlarway wrote:
| Same here. I definitely went through a powerline, alias,
| huge vimrc, etc phase, but it turns out just sticking to
| the base toolset is pretty handy.
|
| I can sit down at (or ssh into) any machine and be
| basically just as productive, and it also turns out that
| I just always want to know more than nicely fits into the
| prompt anyways.
|
| There's something to be said for accepting the defaults
| of a tool, and learning to use them well. Customization
| is powerful, but... I think most times it's not the right
| call until you're already an expert in the tool at hand.
| ericmay wrote:
| Same here, I also find that aliases for speed introduce
| unnecessary complexity and mental overhead later on. It's
| not much, and for other people it doesn't matter or they
| have a different preference, but that's what I prefer.
|
| Sort of contrary to that I really enjoy the maximalist
| shells. A computer should be fun to use!
| gumbojuice wrote:
| I don't use aliases, but abbreviations that expand to the
| actual full command. Helpful to type less and history has
| the exact.
| acedTrex wrote:
| See when I don't have a prompt I forget to run those
| things and just autopilot through a lot of commands
| before I realize Im on the wrong branch.
|
| For example if I have say 3 worktrees open in 3 seperate
| tmux tabs and are context switching between them (very
| common when reviewing multiple PRs from my devs)
| Sometimes i will get the tabs mixed up, which worktree is
| where etc and just autopilot a bunch of commands meant
| for one tree into a different one and its quite annoying
| to clean up.
|
| The prompt has generally stopped me from doing that.
| alganet wrote:
| On tmux, I use split panels more often than tabs.
|
| Usually, there will be from 2 to 8 panels of different
| sizes.
|
| This gives me spacial short term memory: I know what each
| shell is by the panel position.
|
| I can zoom on then to bring them full screen (ctrl+b z)
| if I'm going to do anything that requires more space,
| then zoom out to the panel arrangement when I'm done.
|
| Sometimes I'll name prompts (eg `PS1='stg$ '`), specially
| when working with ssh, but that's rare.
|
| What inspired me to work this way was this video on the
| acme editor: https://www.youtube.com/watch?v=dP1xVpMPn8M
| 1vuio0pswjnm7 wrote:
| "The only tool that stood the test of time is tmux."
|
| tmux comes from BSD rsther thsn GNU/Linux.
|
| What is the default shell in OpenBSD
|
| starship does not support it starship
| init ksh ksh is not yet supported by
| starship. For the time being, we support the
| following shells: * bash * elvish *
| fish * ion * powershell * tcsh
| * zsh * nu * xonsh * cmd
| Please open an issue in the starship repo if you would
| like to see support for ksh:
| https://github.com/starship/starship/issues/new
| msgodel wrote:
| I just run git status manually, I always explicitly specify
| the branch when I do anything that touches a remote,
| everything else you can undo if you have to.
| kccqzy wrote:
| I'm highly aware of which branch I'm on. Because it's
| because I don't use any scripts or automation that switches
| branches; I only ever switch branches manually so I have
| that awareness.
| fkyoureadthedoc wrote:
| I only switch branches manually too, but I work in many
| repos and come back to stuff after days sometimes.
| gcarvalho wrote:
| Even if I know my current branch, having my prompt show
| me untracked/uncommitted/unpushed changes helps to
| identify if something didn't work because I'm in a dirty
| state, or if something I ran (unexpectedly) caused a
| dirty state.
|
| For example, I don't expect running scripts/build.sh to
| modify tracked files in the repo. Seeing part of the
| prompt go from "" to "?2!3" (two untracked, three changed
| files) makes that glaringly obvious.
| slightwinder wrote:
| How well does this work when you work on multiple repos
| with longer pauses inbetween?
|
| And the Branch is also an unintrusive reminder that you
| are in a path under versioncontrol.
| jonhohle wrote:
| not op, but if I haven't been in a working directory for
| a while, I always run `git status` anyway. Then I know
| the branch and any out of date files. I usually run `git
| pull ---rebase` and get everything back up to date. I try
| not to leave broken branches around, so It's rare that
| knowing which branch I'm on is an issue.
| jt_b wrote:
| oh-my-zsh default prompt mode for git branches is for me!
| super clean. need to familiarize myself with some more of
| their shorthand commands.
| freeopinion wrote:
| As a complete aside, and not to argue with you at all: I
| think it might change your life to take a good look at jj.
| I just mention this to try to be helpful to you.
| skydhash wrote:
| Manual git status is enough for me.
| meesles wrote:
| Problem is you can't get timestamps and run times of your
| commands 'when you really need it', unlike almost everything
| else
| bayindirh wrote:
| Why the timestamps are that important? Honestly asking.
|
| You can always time your commands with "time".
| stirfish wrote:
| I personally use a modified zbell (in zsh) to give me a
| notification when a command finishes after 30 seconds,
| and send me an email if it takes over 2 minutes.
| bayindirh wrote:
| I generally use Konsole's "notify when program exits"
| feature. For longer tasks, I have a small tool which I
| pipe to, and it sends me push notification with the
| output (if I prefer).
| stirfish wrote:
| I had a tool I'd pipe to, but I'd often only think about
| it after I'd realize that the command was going to take a
| while. A push notification sound cool; I used email
| because I knew how to hack it together with curl.
|
| Here's _one_ zbell implementation, not sure it 's the
| original but it looks like it does the trick:
| https://gist.github.com/oknowton/8346801
| bertmuthalaly wrote:
| When you're debugging, especially a complex system,
| especially during an outage or postmortem, understanding
| when your commands executed relative to when your log
| lines appeared is really helpful.
| bayindirh wrote:
| Oh, that's an interesting use case, alright.
| styluss wrote:
| sounds like your describing
| https://linux.die.net/man/1/ts
| kccqzy wrote:
| That's a poor and hacky substitute of using Linux audit
| features. It's perhaps the right robustness/complexity
| trade off for my personal machine, but for work they
| likely already have audit features turned on and you can
| access the timing from there.
| hiAndrewQuinn wrote:
| I think you need to put a number on "likely", here. 80%
| of all workplaces, maybe? Even that seems a little high.
| There are a surprising number of devs who have never even
| heard of auditd. It's just not the kind of thing most
| people come across in their day to day work unless they
| go digging for it, or come from a security or DevOps
| background or something.
| xorcist wrote:
| That's a good reason to have timestamps in the history,
| which you should.
|
| Something like export HISTFILESIZE=
| export HISTSIZE= export HISTTIMEFORMAT="[%F %T] "
| shopt -s histappend
|
| really ought to be default in bash.
|
| It's not as clear why you need it in the interactive
| prompt.
| hiAndrewQuinn wrote:
| I didn't make it quite as clear as I should: the reason
| to have it in the prompt is mostly so that you, or
| someone you're working with, can spot a trend you may not
| consciously think to look for if the timestamps weren't
| in front of you.
|
| It sounds silly, but it has saved my butt more than once.
| Especially if you have bugs that e.g. only show up once
| per hour on the hour, and are otherwise fine.
| horsawlarway wrote:
| For a personal workstation - you should never "really need
| it".
|
| It's a personal machine and should be treated as
| disposable. Doing anything less is fairly irresponsible.
|
| So sure - turn on timestamps for your ssh bastion (although
| it should be in the logs already...), or turn them on for
| the ci/cd pipeline (not that you should need them there
| anyways, since it should be dumping tons of timing info
| already).
|
| But a personal machine? Plain ol' ">" is plenty.
|
| Not that there's anything wrong with a maximal prompt
| either... I've definitely done the "configure all the
| powerline settings!" thing. But I also don't mind a simple
| ">" or "#".
| hiAndrewQuinn wrote:
| Well, that's why you build it into the prompt. So you don't
| give yourself the opportunity to forget.
| mechanicum wrote:
| As an alternative, perennial HN recommendation atuin
| (https://atuin.sh) logs time, duration and exit code (among
| other data) for every command.
|
| That way you only have to look at it when you need it, and
| you can also figure out what you were doing last
| week/month/year if necessary.
| ljm wrote:
| 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.
| andrewflnr wrote:
| The exit code of the last command is useful for similar
| reasons.
| MyOutfitIsVague wrote:
| 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 |
| +-----------------+------------------+
|
| It's really nice, because it doesn't just tell you time between
| command executions (or rather time between commands finishing),
| but the actual runtime duration of the command.
| layer8 wrote:
| 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.
| hiAndrewQuinn wrote:
| Per the Bash `history` manpage: int
| history_write_timestamps If non-zero, timestamps
| are written to the history file, so they can be preserved
| between sessions. The default value is 0, [...]
|
| So this isn't true by default on many machines unless it is
| explicitly turned on. Once you do have it on, of course, then
| I agree.
| layer8 wrote:
| That's why I wrote "using HISTTIMEFORMAT", which turns it
| on. It's reasonably common to do that.
| bedlamite wrote:
| This is why I really appreciate tools like Atuin. It augments
| your history with extra data such as the working directory,
| exit code, time to run command.
| nine_k wrote:
| 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.
| perplex wrote:
| Happy user of spaceship prompt for zsh: https://spaceship-
| prompt.sh, and, among other things, it runs repo status
| asynchronously.
| Aeolun wrote:
| I really like this one for just being a single install and then
| no more fiddling. I don't have time for any of that shit, but I
| do want to know whether my current shell is on node 20 or 22,
| rust stable or nightly. Getting all of that without extra effort
| is great.
| hu3 wrote:
| I'm a long time user of https://github.com/ohmybash/oh-my-bash
|
| It would be nice to have a comparison and reasons to change from
| popular tools.
| nodesocket wrote:
| Came here to ask the same. Long time ohmyzsh user, and
| wondering what new features / benefits Starship has.
| pasc1878 wrote:
| Basically it is quicker.
|
| I also expect it has everything that you have in your prompt
| so is a direct replacement without losing anything.
| hu3 wrote:
| I don't doubt that it can be quicker but:
|
| 1) I don't recall having a problem with prompt speed.
|
| 2) Are there any benchmarks?
| lknuth wrote:
| I found the config a lot nicer. It was very easy to custimze
| to my (very minimal) liking. The config is easily readable.
| And its portable to any supported shell.
|
| Most shells can probably do everything this can as well and
| if you're already familiar with the archaic syntax there is
| probably limited use for you.
|
| For an idea, here is my current config https://github.com/Luk
| asKnuth/dotfiles/blob/main/zsh/.config...
| drcongo wrote:
| I love Starship. Having built a decent enough powerline prompt
| for zsh in the past, and really hating PS1, I've found Starship
| to be incredibly useful for building the exact prompt I want,
| with full colour, and never ever wigging out at anything. One
| simple toml file on every machine I ever ssh into and everything
| I need to know about the session is there at a glance.
| kuon wrote:
| It looks nice.
|
| I usually like simple prompt, but there is one feature I really
| like, it's the timestamp. It helps me remember when I did
| something and how long it tooks.
| BSDobelix wrote:
| Atuin and Starship the same Day on place 1? Next zellij :)
| ellieh wrote:
| Atuin was until it was bumped to page 2/3 and beyond :(
| anuramat wrote:
| I can't imagine interacting with computers without fzf, zoxide
| and nix anymore; everything else feels relatively
| inconsequential
|
| Wondering if there are any other life-changing tools I'm
| missing out on...
| hiAndrewQuinn wrote:
| I've got a whole list of tools you might want to consider
| checking out over at [1]. The scripts themselves are Ubuntu
| specific, but the binaries are ones I've all found very
| helpful over the years.
|
| In particular I'd call out `gron` (make JSON greppable) and
| `lnav` (Datadog-level log filtering but for local machines
| and files) as very helpful for dev work.
|
| [1]: https://github.com/hiAndrewQuinn/shell-bling-
| ubuntu?tab=read...
| jamesponddotco wrote:
| I live in the terminal, so I wrote my own prompt ages ago when I
| started learning Go[1][2], and before that I had a simple prompt
| in bash.
|
| I like to keep things very simple and fast, so the directory and
| the git branch is all I need. I wonder if people really use all
| that information or if they set it up thinking they need it, but
| then never do.
|
| [1]: https://git.sr.ht/~jamesponddotco/gosh
|
| [2]: I should probably update that now that I know a "bit" more
| Go.
| williamdclt wrote:
| The only thing I add is the time (hh:mm:ss), it's often-ish
| useful to roughly know how long a command has been running for
| (or how long it took after it completed)
| jayknight wrote:
| The `cmd_duration` starship module can additionally tell you
| how long the previous command took:
| https://starship.rs/config/#command-duration
| sockboy wrote:
| I like how minimal prompts keep focus, but adding just the right
| context like AWS profile or last command status really saves time
| and mistakes. Starship hits a good balance here.
| beej71 wrote:
| The one thing I'd miss from my prompt if I went full $ is the
| hostname. And even with it in there, I still f it up sometimes.
| bbkane wrote:
| I ended up writing my own zsh prompt a few years ago and it's
| worked like a charm for my simple needs:
| https://github.com/bbkane/dotfiles/blob/master/zsh/dot-zshrc...
|
| ends up looking like this:
| https://github.com/bbkane/dotfiles/blob/master/zsh/README_im...
| oweiler wrote:
| I use Starship without any customizations and its good enough for
| my every day use.
| babo wrote:
| Produced a 151 characters long prompt in my current development
| directory. This is really a starship, but I'm a pedestrian.
| smurfsmurf wrote:
| Looks good, though unfortunately I really can't stand icons in my
| terminal. It looks pretty, but it smudges meaning and, if you
| suffer from chronic migraine like me, it makes it incredibly hard
| to scan.
| lknuth wrote:
| Agreed, you can replace them easily:
| https://github.com/LukasKnuth/dotfiles/blob/main/zsh/.config...
| bodge5000 wrote:
| I know Starship isn't zsh specific but I guess its tangentially
| related, does anyone know what the default zsh config is on
| MacOS? I got quite used to it, and now I'm on linux I'd like to
| replicate it. The closest I've got is using the eastwood theme on
| oh-my-zsh but it's not quite the same (I dont even think MacOS
| using oh-my-zsh out the box, but its got all the nice git stuff)
| JimDabell wrote:
| /etc/zsh:
|
| https://pastebin.com/kjwQ97z1
|
| /etc/zshrc_Apple_Terminal:
|
| https://pastebin.com/kfKF5ych
| yankcrime wrote:
| Ignore the haters - I too am a fan of minimalism in my terminal
| since I don't appreciate unnecessary clutter or decoration, but
| context is king and Starship can be configured as such.
|
| By default my prompt is a shows me the current directory, the
| time, and a single character '%'. If I set something in my
| environment for which I need to be contextually aware - i.e if I
| have KUBECONFIG or OS_CLOUD - then the prompt is updated with the
| detail. Similar for languages - it'll automatically show me the
| version of Go or Python or whatever based on a few factors, all
| of which I can control.
|
| The reason I love Starship is that it's made all this very, very
| easy to configure - instead of having to wade through arcane Zsh
| configuration or additional plugins, Starship makes it easy. It
| also adds negligible overhead to initialisation, especially when
| done so via evalcache [0]
|
| [0] https://github.com/mroth/evalcache
| Henchman21 wrote:
| Genuine question for all the people putting timestamps in your
| prompts: do you never look at your command history and see that
| they're all timestamped?
| jethro_tell wrote:
| I do know that though that assumes some things about os and
| shell.
|
| Run a full screen term on my machine for a good chunk of my
| workflow and I just like to have time and battery in my term. I
| render it as '(15:35) [80} <hostname> $ ' and for boxes without
| batteries it's just '(15:35) <hostname> $ '
|
| Some times I'll go back through my scroll back and look at the
| time when I'm trying to figure things out. Or when I run a
| command that generates a ton of output, I'll note the time and
| run the command then later search back to the time in scroll
| back to start at the top of the log.
|
| None of these are features I truly miss on a vanilla box, I can
| look at a clock or watch and will put a comment into the scroll
| back to find later.
| Henchman21 wrote:
| I think we're quite similar I just put my time display in the
| tmux status bar :)
|
| Just so I am clear, use your prompts as you see fit -- I'm
| just trying to understand how others work. Thanks!
| hiAndrewQuinn wrote:
| Per the Bash `history` manpage: int
| history_write_timestamps If non-zero, timestamps are
| written to the history file, so they can be preserved between
| sessions. The default value is 0, [...]
|
| So this isn't true by default on many machines unless it is
| explicitly turned on.
|
| I could find no command line history for Bash when I poked
| around. I use the fish shell, however, which does embed
| timestamp data by default - but I rarely think to look there
| when the detail might be pertinent. C'est la vie.
| Henchman21 wrote:
| Aha now that makes some sense. I am a bash user-- and I'll
| admit my settings are OLD. So old I've forgotten the defaults
| entirely. Thanks for the reminder :)
| d332 wrote:
| It's a different use case. If you run a slow command and check
| terminal later, you can see how long it took.
| Tmpod wrote:
| I tried starship a few years ago and found it too "extra" and
| sluggish. I'm sure it may have improved in this time, but I ended
| up sticking with the excellent Hydro[0], only for fish though.
|
| It's very minimal while having useful features: - exit codes,
| even for pipelines - git branch, status (displayed as a dot if
| your tree is dirty) and ahead/behind counts - command execution
| time (if above some configurable threshold) - truncated/minified
| $CWD, always maintaining the git root's name (I sometimes like
| it, sometimes don't; fortunately, it's very easy to change) -
| current vi-like mode (I don't use that)
|
| It's very fast and async (prompt repaints don't block your input
| or running commands), and totals 132 lines of fish (according to
| cloc[1]). It's also very customisable through variables, which
| can be declared as universal to instantly change on all sessions
| you have open.
|
| If you're on fish and like this feature set, definitely give it a
| shot, or at least look at the code as a base for a bespoke prompt
| :P
|
| [0]: https://github.com/jorgebucaran/hydro [1]:
| https://github.com/AlDanial/cloc
| bullman wrote:
| Fan of starship here. wanted to drop a few comments based on what
| I seen so far
|
| Love the performance. Written in Rust and compiled to binary,
| it's _much_ faster than either python-based powerline, the bash-
| shell-based ohmybash and zshell-based ohmyzsh and spaceship.
|
| You can use it for zsh, bash, sh, fish. but you can also use it
| for both MS Windows CMD and Powershell. I don't believe any other
| prompt tools can do all at the same time. And a single config
| file can control all of them on your system.
|
| The default config is just that - a default. Too much
| information? you can change it. dont like icons? you can remove
| them.
|
| At almost 100 modules to choose from, it's customization options
| are nearly limitless
| tristor wrote:
| I have been using ZSH + various add-ons for ages, originally oh-
| my-zsh, and lately Prezto. I also somewhat maintain a fork of
| Prezto with improvements for Mac, mostly for my own personal use
| (although apparently quite a few others are using it as its
| gotten several stars). Historically I used powerline9k,
| powerlevel, powerline10k, and finally pure for the longest time.
| I switched to starship the last time it got posted on HN that I
| saw, which was around 2 or 3 years ago, and I've stuck with it
| since. For one thing, it had a mode to configure it exactly like
| pure very simply out of the box, and the second reason was
| because it was significantly faster. By moving more of the logic
| into starship and out of ZSH, it greatly reduced the performance
| hit I took by adding additional information into my prompt.
|
| I know not everyone likes blinged out shells, but if you're a ZSH
| user, it fits very well into the Prezto/oh-my-zsh model.
| askl wrote:
| Looks pretty nice, but the name seems unfortunate. (unless it
| crashes on every launch)
| pseudospock wrote:
| It has support for fish shell... I'll pass.
| bigfishrunning wrote:
| support for a shell you don't use is a negative? why? I don't
| personally use it, but I don't mind if other people do --
| what's the problem here? just curious.
| lend000 wrote:
| I'm trying to understand what they are demonstrating with the
| "false; true" commands in the little video loop. Can someone
| chime in?
| zygentoma wrote:
| `true` returns exit code 0
|
| `false` returns an exit code != 0
|
| The prompt indicates whether the last command returned exit
| code 0.
| grep_name wrote:
| Interesting. I've been using the pie theme fish for years, and
| have various problems with it, but have not found something in
| OMF which is better for me. I also don't like the OMF dependency
| in my configs.
|
| Maybe it's finally time for me to sit down and write my own shell
| prompt once and for all. I wonder if I can make it context-aware
| of fish's editing vs normal mode when vi mode is enabled
| taude wrote:
| I used to use Starship awhile ago, switched to powerlevel10k.
| Trying to figure out if there's any thing there for me to want to
| try starship again? I remember powerlevel10K was really easy to
| get going.....
| m000 wrote:
| I would be very curious to see an age demographic chart of people
| using e.g. Starship.
|
| Personally, over time, I have stopped caring too much about
| prompt customization. I concluded that, no matter how carefully
| you curate your prompt, 90% of the information shown will be
| irrelevant 90% of the time*. After a while, your brain will start
| perceiving this as visual clutter and filter it out, to the point
| you may even forget the information is there, right in front of
| your eyes.
|
| And for the things that matter, you probably need more details
| than any prompt can show you. E.g. are there changes in your git
| branch? Ok there are, good to know, but which files have changed?
| Just knowing that there are changes is not really actionable
| information. You need to run additional commands to get
| actionable details.
|
| * the numbers are completely arbitrary, but you get the picture
| bityard wrote:
| 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.
| skydhash wrote:
| I still have free time, my shift to default config and stable
| software was caused by how many workfkow changes for no
| reason I could stomach. I rarely need the latest features.
| Getting things to work and expecting to stay working for a
| while is the basic premise of computing.
| deathanatos wrote:
| 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.)
| >>
|
| I also translate signals, so I get "last command exited on
| SIGSEGV", or so.
|
| It's also useful the other way: when a program emits and error
| and exits with "success".
| __float wrote:
| I like the exit code feature a lot; Starship does that with
| my config in a subtle color change.
|
| My shell customization is largely throwing Starship in (so it
| looks the same on all the machines I use -- Ubuntu servers at
| work, macOS at home, nixOS/Fedora/etc. servers for personal
| use.) and a starship.toml I wrote once and now leave alone.
| m000 wrote:
| That's useful indeed. Did you custom-code it, or is it e.g.
| an ohmyzsh plugin or something?
| tclancy wrote:
| Oh, how do you automate that? I usually add a "& say done |
| say failed" to long-running tasks if I remember to do it.
| teo_zero wrote:
| In bash, it's enough to remember that $? expands to the
| exit code of the previous command, and $((x)) evaluate x as
| an integer expression, including the ternary operator
| x?y:z.
|
| For example the following prints the exit code in green if
| zero, in red otherwise:
| PS1='\[\e[$(($??31:32))m\]$? \[\e[39m\]'
| rcarmo wrote:
| 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 :)
| m000 wrote:
| It's always nice to have an impromptu HN poll. We may have
| been missing and didn't know :)
|
| And now that you mention it, next year will be my 30th Unix-
| versary. Time flies... Still not a greybeard though.
| Twirrim wrote:
| 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.
| Twirrim wrote:
| 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\] "
|
| timestamp, who I am, what box I'm on, where I am.
|
| 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.
| inejge wrote:
| > 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.
| eddd-ddde wrote:
| I'm 90% sure what you described is fish default prompt.
| natebc wrote:
| 26 years with Linux. I use starship but primarily because I
| administer multiple kubernetes clusters and having the kube
| context staring me in the face is critical. I don't adjust the
| default config more than just making sure the kube bits are
| enabled.
|
| That said my vimrc is 2 lines that i can configure manually, I
| don't touch bash config from Debian defaults and my fish config
| is vanilla save for a handful of functions because I'm a lazy.
| My ssh config is pretty heavily customized but mostly around
| what keys/usernames to default to for which hosts (see previous
| about lazy).
| NelsonMinar wrote:
| Starship was the first time I meaningfully changed my shell
| prompt in nearly 30 years.
| Merad wrote:
| I've been coding for 20 years, I very much like having git info
| in the prompt. Even if it doesn't tell me everything (and it
| often doesn't) it _is_ a reminder that I have uncommitted
| changes, or haven't pushed yet, or a stash that I might have
| forgotten about.
|
| I played with Starship for an hour this morning - the joys of
| 50 person planning meetings - but ultimately uninstalled it. I
| did like some of its options like command timing and
| success/error, but all the tool versions ultimately just felt
| like noise. Not worth the effort to maintain a complex custom
| config to trim it down to what I'd want.
| spiantino wrote:
| Starship + Ghostty has been an awesome (and fast) experience.
| iloveitaly wrote:
| I've been using it for awhile and love it:
|
| https://github.com/iloveitaly/dotfiles/blob/master/.config/s...
| t1234s wrote:
| Is piping curl output to sh ever a good idea?
| spapas82 wrote:
| Well done for supporting windows cmd (through clink) ; most shell
| tools don't take care about us windows cmd users !
| baruchel wrote:
| Can't find the URL again for a funny (and probably universal)
| custom prompt: you had to do some curl <url> |
| sh
|
| then you could see on your terminal thousands of various tests
| related to your installation, then several megabytes being
| downloaded with progress bars, etc.
|
| At the very end of the whole process, the whole stuff would
| vanish into writing PS1="$ " at the end of your ~/.bashrc
|
| Of course, the very same prompt was used whatever your install
| could be. I think it was some joke making fun of all these crazy
| and heavy custom prompts all around.
| skrebbel wrote:
| I'm impressed at how seriously they take "for any shell". It even
| works with cmd.exe!
| woile wrote:
| starship has been excellent, and gives me the right context all
| the time. Like I'm running inside a nix shell, the python venv is
| enabled or the git branch.
|
| Configuring it with home-manager was as simple as:
|
| programs.starship.enable = true;
| PeterWhittaker wrote:
| What am I missing? I went to the site, but I can find nothing to
| suggest _why_ I might want to use this. Are there examples that I
| 've missed, likely owing to having been heads down chasing a
| pernicious heisenbug all day?
|
| Given that I do like my shiny prompt, which shows me:
| The result of the last command (in green, red, or purple)
| user@host:currentDirectory current branch, if in a repo
|
| with the last line showing summary git status, if in a repo, and
| background jobs, I suspect I might be their market, but I cannot
| see a _why_ anywhere.
|
| (Green: Last command good, e.g., exit 0) (Red: Last command non-
| zero exit, with a special indicator if it was interrupted)
| (Purple: Last command suspended, and few other things)
| microflash wrote:
| I'm surprised by people conflating customizability with
| maximalism. Yes, the default configuration is a bit too much but
| you can turn the knobs to reign it in. I work on multiple AWS
| environments, different application runtimes, and so on. Having
| some context in the prompt has been very helpful for me. I maybe
| biased though since I've used Starship for years paired with
| Nushell.
| pixl97 wrote:
| Warning: Improper use of Starship may cause it to explode in your
| test harness.
| usmanity wrote:
| I started using Pure prompt since I'm only ever using zsh and it
| seemed to cut down a lot on the setup required, I do have to
| spend like 15-20 mins on a new computer to get everything working
| as expected but once it gets going, it feels like the best mix of
| customization and speed.
| exiguus wrote:
| I have several use-cases / problems I solve with my prompt:
|
| - See current git branch (to not mistakenly work or commit into
| the wrong branch)
|
| - See git has changes (to stash them before switching branches)
|
| - See the current language/engine version (like go v1.24.2,
| because i use tools like gvm, sdk, nvm or rustup to switch
| version in projects and i want feedback that i have the
| correct/expected language version enabled)
|
| - See that i am on my local or a remote machine and k8s context
|
| That's mostly it. Of course, I can do this by writing my own
| prompt, but I found out that Starship does this for me, basically
| out of the box, on any machine and terminal, in a very nice-
| looking way. Also, I am not a fan of fancy-looking prompts, so
| visually, Starship fits best for me.
| thibran wrote:
| Too bad that we still use text based shells in the year 2025. We
| should have come up with a graphical shell that is as powerful
| and flexible two decades ago.
| dirkg wrote:
| I've always liked powerlevel10k, or its equivalent tide for fish
| shell, which I much prefer over bash/zsh. Its fast, async, has
| everything you need, and is much easier to configure.
|
| I've always wondered why someone doesn't just bundle a nice
| looking shell prompt with common nerd fonts and make it the
| default in a single package you can install.
| nh2 wrote:
| With or without starship, one problem I have with zsh prompts is
| that when I press Enter, there is still a visible delay where for
| a fraction of a second, the cursor moves to the beginning of the
| next line.
|
| This makes a nasty "flashing" effect.
|
| If I keep Enter pressed, the cursor is permanently visible at
| offset 0 in the lowest line.
|
| If the prompt is ultra-fast (e.g. plain root shell prompt on
| zsh), it happens less (e.g. only 50% of cases), but as soon as
| the prompt does anything, it's very visible.
|
| I observe this with many terminals (gnome-terminal, wezterm,
| kitty, alacritty, xterm).
|
| The only terminal I tried that doesn't have this problem is
| urxvt, where it looks perfect.
|
| Video repro: https://nh2.me/flashing-cursors-on-newline.mp4
|
| Why, and is there a way around it for those other terminals?
___________________________________________________________________
(page generated 2025-06-24 23:00 UTC)