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:
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.
I love nushell. You can also query by friendlier things than index:
history | where exit_status == 127 | last | get duration
2sec 410ms
The syntax ends up very clean looking since the data going through the pipes is typed, and the error messages are top notch
× Types 'duration' and 'int' are not compatible for the '-' operator.
╭─[entry #47:1:2]
1 │ (history | where exit_status == 127 | last | get duration) - 10
· ───┬─── ┬ ─┬
· │ │ ╰── int
· │ ╰── does not operate between 'duration' and 'int'
· ╰── duration
╰────
I never bothered configuring my prompt at all because, inside emacs, I could already see most of what I needed in the editor itself.
In fact, I only set up Starship when I started to do more pairing. It wasn’t for my benefit as much as it was for those watching my screen and checking the work, especially when operating on prod and confirming what we wanted to run. I just load up a separate terminal app for that so I don’t have to walk people through my setup.
Current time in a more human-readable format is very helpful sometimes. Also, the exit status of the previous command, if nonzero, is also very helpful when anything fails.
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.
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.
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.
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.
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.
Then you have to remember to run this regularly. Which i regularly forget in tmux autopilot mode. The prompt serves as one last headsup reminder. Even then sometimes I dont look at it and have to roll some stuff back
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.
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.
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.
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.
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.
"The only tool that stood the test of time is tmux."
tmux comes from BSD rather thsn GNU/Linux, or Windows
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
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!
I’m a researcher and work on small projects with 1-3 people (most of the time it’s just me prototyping stuff alone). I then tend to work on a branch for weeks at a time, so the git branch provides very little information compared to the space it takes in a prompt.
If I was switching branches every 5min, it would be useful.
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.
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.
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.
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.
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.
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 "#".
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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
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.
I've tried prompts in the past, and they mostly annoyed me, or never showed me useful information. I've been a happy starship user for several years now. I've got the config tweaked so that it only shows me things I specifically care about. It's lightning fast.
As a counterpoint, one of the most useful customizations I've made to my prompt is to emit the exit status of the prior command. Knowing that something failed is a useful signal, esp. when sometimes the thing failing just fails to emit any output that indicates that it failed.
I only emit it if the prior command fails, too, so it doesn't clutter things the 90% of the time things are working.
» true
» false
(last command returned 1.)
»
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".
I think (if I am reading TFA's code right) unlike the article, I'm using zsh's module functionality, so the Rust here is a .so that is loaded directly into the shell's memory. (I.e., I do not have to fork/exec a separate Rust bin to compute the prompt, though I think zsh might fork-but-not-exec for computing the prompt itself.)
The latter is, of course, somewhat more complicated in some senses. (Esp. on macOS, which work forces me to use, where dlopen(2) is just utterly insane.)
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:
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.
I think we can generalize this into the overall computing environment. When I was younger, I was that kid building my whole OS from source via Gentoo, with all the CPU-specific flags and optimizations. I had a very detailed window manager configuration (fwvm2 maybe?), a .bashrc full of aliases and functions for every occasion. And yes, a custom prompt.
I think these kinds of over-optimization rabbit holes are a good learning experience, but I compare it to woodworking. A woodworker just starting out will spend most of his/her time building or refining the tools they need, learning techniques, coming up with ideas/designs and testing them, etc. But eventually the point comes where you have to get Real Work done and the tools and jigs have to wait until the weekend.
Linux is still my favorite desktop OS, but these days I just run Debian and KDE because "free time" is not a thing I have anymore and I care more about getting things done than having the most optimal computing experience.
I 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.
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 :)
Same here. I’ve been using Unix of some flavor or another since 1989 and generally prefer minimalism and simplicity - but I also prefer “opinionated good defaults”, and starship gives me that. (I’ve even switched to Fish, because it does well with no config absolutely basic table stakes stuff OOTB that bash/zsh need a ton of garbage for.)
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.
> 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.
This is me. All I need to know is my current directory, and the status in color of my last command (red for failed, green for zero [my prompt starts with ->]). That's it.
It also gives me the current branch in a directory that has git, just so I'm sure of what I'm working on-- but most of the time that's handled by whatever editor I'm using.
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).
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]
I also have very few always on segments, and many conditional segments that only show up when useful. Host shows when I'm not on the usual, user when I'm not me, and stuff like that.
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
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.
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.
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)
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
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
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.
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.
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.
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.
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.
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:
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.
100ms to render a prompt are meaningless. You can just type commands and run them asynchronously. I do this all the time when a previous command is taking a little extra to complete but I already know what my next command is going to be.
we optimize for code runtime but not for our own typing latency
100ms optimization is a lot different for a CPU or a human brain.
I'm not defending having the entire system log dumped out on every prompt but a few amenities are worth a few milliseconds computation time for a human.
Besides, I don't see how, for example , having your prompt take those 100ms to print a git branch or status breaks your "flow" yet having to type out the commands yourself and taking longer doing it doesn't.
Its a balance between bloat and and usability like so many other things, but, to me at least, being on either extreme of bloat or extreme-minimalism seems counterproductive.
The delay is certainly frustrating. I use a patched version of kitty terminal that moves starship prompt to the bottom of the window, similar to vim and emacs. Since modeline updates are asynchronous, the shell prompt is very snappy even in big git repos. The downside is that you have to patch kitty and I never bothered to test my personal pet project on anything else than Linux.
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.
counter-point: having to constantly track git status in your head, and needing to type commands to remind yourself, is a far bigger distraction. Optimize to avoid context switching, not for a few ms latency.
FWIW, I switched from zsh default to starship and didn't notice any perceptible difference. But I certainly notice when I mess up my git commits!
If you're used to, say, VS Code or the GitHub online editor where the lag between pressing a key on the keyboard and a corresponding character appearing on the screen can be on the order of tens of thousands of milliseconds, then 100 ms will seem like lightning.
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.
I've been a happy starship user for a few years at this point (after a long time with oh-my-zsh). For me, it's killer feature is the `starship.toml` file. Gone are the days of arcane bash escape sequences to style the prompt. It's a well-documented shape and easy to reason about. So no matter if you got maximalist or minimalist for your, it's easy to tweak. That rocks.
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.
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)
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.
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.
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.
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.
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.
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.
input_delay doesn't seem to address this in general: Even when set to 50 (which is very noticeable), the cursor on the next line just appears with some delay.
Interesting, In zsh I experienced the exact behavior you described and setting input_delay to 10 completely resolved it. To be fair, when testing my PS1 was simply '%m$ '.
I just benchmarked 'starship prompt' and when in a directory managed by git, it can take well over 10ms. I imagine with a more advanced configuration it would take even longer. urxvt must be doing something special.
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.
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.
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.
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.
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?
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.
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.
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 :)
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)
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
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.
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.
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.
Starship only supports this in PowerShell for whatever reason.
Edit: Doh. I see what you linked to now. Yea, maybe it does work in more than just PowerShell now?
Transient prompt basically removes your prompt decorations and replaces it with just `>` in your scroll back history in your shell sessions. In my case it's a slightly more complex transient prompt (datetime and exit code of the command), but still greatly simplified.
Makes cut-and-paste of history in to docs and stuff super nice.
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.
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
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.
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.
My earliest background as a shell user was as as system administrator (back in "the day", let's say), and forks are always potentially expensive, and often the reason you're opening a shell session in the first place (to diagnose resource contention or exhaustion, for example). There have been lots of times when one more fork is too much to take. (Which also, yes, makes it "interesting" to figure out what you can run in your shell session, too).
A non-forking prompt command is an absolute requirement for me and always has been, so I did this in pure shell. It's not a lot of code but it's a little tricksy.
If I still used bash, starship would be a non-starter for me, in part, since it's fork/execed in the prompt command. Further up this thread someone says that the zsh installation is different and it's a native shared library that gets loaded into zsh. That seems neat.
(The other reason it's a non-starter is that maybe I can stomach sending over a dotfile to various systems, but selecting a platform-specific native binary is too much configuration management to be done to prepare for an SSH session/kubectl exec. Eventually I made my peace with doing this for emacsclient so I could have local editing of remote files, but that's a lot less critical of a piece to miss than something that appears in your prompt. Conceptually, if you want to ship over/config-manage a native binary, you might as well install a better shell, which became a compelling argument to me when I switched to Powershell).
> 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.
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.
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.
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).
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.
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.....
Powerlevel10k is perfect for me: fast, configurable, looks really good. It is not maintained anymore though :( I guess I'll keep using it while it lasts
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.
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.
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:
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.
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.
Fish shell detracts from people learning (and maintaining) to use POSIX compliant shell scripting. Professionals should be ready at a moments notice to use bash, zsh, and ksh. Also good to be familiar with a csh, (I would accept tcsh). Learn to use the tools of the trade, not toys.
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:
[1]: https://github.com/hiAndrewQuinn/shell-bling-ubuntunushell does that out of the box:
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.I love nushell. You can also query by friendlier things than index:
The syntax ends up very clean looking since the data going through the pipes is typed, and the error messages are top notch (fingers crossed hn doesn't mangle that...)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.
The exit code of the last command is useful for similar reasons.
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.
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.
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.
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:
starship.toml: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.
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.
I only switch branches manually too, but I work in many repos and come back to stuff after days sometimes.
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.
"git status" is all you need then.
Then you have to remember to run this regularly. Which i regularly forget in tmux autopilot mode. The prompt serves as one last headsup reminder. Even then sometimes I dont look at it and have to roll some stuff back
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.
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.
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.
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.
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.
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.
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
"The only tool that stood the test of time is tmux."
tmux comes from BSD rather thsn GNU/Linux, or Windows
What is the default shell in OpenBSD
starship does not support it
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!
I don't use aliases, but abbreviations that expand to the actual full command. Helpful to type less and history has the exact.
I like this. What do you use to accomplish this?
I don’t know exactly what they’re referencing, but Zsh has something like that where you can expand eg filenames and paths from this unique bits.
So if you have
``` src/components/Button.vue src/components/ButtonGroup.vue ```
And you type `nvim s/c/G<Tab>` it’ll expand to the second file’s path.
I guess it depends on your day job and workflow?
I’m a researcher and work on small projects with 1-3 people (most of the time it’s just me prototyping stuff alone). I then tend to work on a branch for weeks at a time, so the git branch provides very little information compared to the space it takes in a prompt.
If I was switching branches every 5min, it would be useful.
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.
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.
Manual git status is enough for me.
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.
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.
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.
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.
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.
Problem is you can't get timestamps and run times of your commands 'when you really need it', unlike almost everything else
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.
After mucking around for an hour trying to get this information into my prompt, I realised atuin already had it.
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 "#".
Why the timestamps are that important? Honestly asking.
You can always time your commands with "time".
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.
That's a good reason to have timestamps in the history, which you should.
Something like
really ought to be default in bash.It's not as clear why you need it in the interactive prompt.
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.
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.
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.
sounds like your describing https://linux.die.net/man/1/ts
Oh, that's an interesting use case, alright.
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.
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).
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
Thanks for sharing the bell. I'll take a look. If you want to try push notifications, I use https://pushover.net as a service.
I developed the tool myself, and it's at https://git.sr.ht/~bayindirh/nudge if you feel like checking it out.
If you want to host the whole push notification infrastructure, you can look at https://ntfy.sh which also can be integrated with cURL.
This is incredibly helpful, thank you. I had no idea push notifications was something I could self-host.
You're absolutely welcome. Me neither. If I could find ntfy.sh earlier, I'd have written nudge for it, not for Pushover.
Well, that's why you build it into the prompt. So you don't give yourself the opportunity to forget.
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.
Per the Bash `history` manpage:
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.That’s why I wrote “using HISTTIMEFORMAT”, which turns it on. It’s reasonably common to do that.
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.
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
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.
Choosing which segments to show is the main the to configure. It's even one of the preset example to hide versions: https://starship.rs/presets/no-runtimes
I agree there's a lot of noise that seems to be there by default.
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:
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.
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.
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".
Oh, how do you automate that? I usually add a "& say done | say failed" to long-running tasks if I remember to do it.
https://github.com/thanatos/dotfiles/blob/master/shell/zsh/p...
That was my prompt when it was written in zsh. Sort of like TFA, I've since moved to Rust:
https://github.com/thanatos/dotfiles/blob/master/zsh-prompt-...
I think (if I am reading TFA's code right) unlike the article, I'm using zsh's module functionality, so the Rust here is a .so that is loaded directly into the shell's memory. (I.e., I do not have to fork/exec a separate Rust bin to compute the prompt, though I think zsh might fork-but-not-exec for computing the prompt itself.)
The latter is, of course, somewhat more complicated in some senses. (Esp. on macOS, which work forces me to use, where dlopen(2) is just utterly insane.)
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:
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.
This and command duration if the command ran longer than 10 seconds are the most useful things to add.
That's useful indeed. Did you custom-code it, or is it e.g. an ohmyzsh plugin or something?
I custom coded it. (Details: https://news.ycombinator.com/item?id=44373575)
I think we can generalize this into the overall computing environment. When I was younger, I was that kid building my whole OS from source via Gentoo, with all the CPU-specific flags and optimizations. I had a very detailed window manager configuration (fwvm2 maybe?), a .bashrc full of aliases and functions for every occasion. And yes, a custom prompt.
I think these kinds of over-optimization rabbit holes are a good learning experience, but I compare it to woodworking. A woodworker just starting out will spend most of his/her time building or refining the tools they need, learning techniques, coming up with ideas/designs and testing them, etc. But eventually the point comes where you have to get Real Work done and the tools and jigs have to wait until the weekend.
Linux is still my favorite desktop OS, but these days I just run Debian and KDE because "free time" is not a thing I have anymore and I care more about getting things done than having the most optimal computing experience.
I 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.
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 :)
Same here. I’ve been using Unix of some flavor or another since 1989 and generally prefer minimalism and simplicity - but I also prefer “opinionated good defaults”, and starship gives me that. (I’ve even switched to Fish, because it does well with no config absolutely basic table stakes stuff OOTB that bash/zsh need a ton of garbage for.)
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.
30 is not that long in Unix time. Or did you mean your 946708560th?
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.
> 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.
That does look pretty good. I wouldn't bother with the time but I like the rest of it.
I'm 90% sure what you described is fish default prompt.
This is me. All I need to know is my current directory, and the status in color of my last command (red for failed, green for zero [my prompt starts with ->]). That's it.
It also gives me the current branch in a directory that has git, just so I'm sure of what I'm working on-- but most of the time that's handled by whatever editor I'm using.
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).
For most of my nearly 40 years in work I had PS1='$ ' and PS2='> '.
A few years ago I progressed to having the current directory in there.
The thought of running a child process to create my prompt every time I hit enter doesn't feel right.
I hope to not age out of trying out new tools other people like!
You won't. I tried uv the other day. But I'm too old to want to run a child process just to draw a prompt.
I should know what git branch I'm in, and if I don't it's a simple command away.
Starship was the first time I meaningfully changed my shell prompt in nearly 30 years.
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
I also have very few always on segments, and many conditional segments that only show up when useful. Host shows when I'm not on the usual, user when I'm not me, and stuff like that.
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
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.Compared to other shells and prompts, the configuration is really straightforward and minimal if you want something mildly complex.
Yeah this isn't minimal, this is maximalism - more information, more characters. They should just embrace being a maximalist prompt.
You can make it as small as you want. Every single feature can be disabled. At the moment mine is relatively minimal
Mine is an even thinner arrow.
# clean, simple, minimal
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.
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:
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)
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
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
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.
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.
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.
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.
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.
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:
If I go in to my checked out version of the linux kernel, probably the biggest git project I've got kicking around: That's typically the worst I see it.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.
100ms to render a prompt are meaningless. You can just type commands and run them asynchronously. I do this all the time when a previous command is taking a little extra to complete but I already know what my next command is going to be.
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.
100 ms is an incredibly long time even for humans.
The delay is certainly frustrating. I use a patched version of kitty terminal that moves starship prompt to the bottom of the window, similar to vim and emacs. Since modeline updates are asynchronous, the shell prompt is very snappy even in big git repos. The downside is that you have to patch kitty and I never bothered to test my personal pet project on anything else than Linux.
https://github.com/mbachry/kitty-modeline
Could prompt tools like this use TUI-style features to edit the displayed prompt after releasing it back to the user? So if kubectl, git, or aws cli takes 200ms to finish it doesn't matter, the data from the output of these commands will appear a few moments after the prompt has been released to the user, so the user doesn't feel like they're waiting for the prompt to be ready.
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!
> we optimize for code runtime but not for our own typing latency
Don't the layers of frameworks mean that the opposite is true.
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.
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.
Well, actually, the Commodore 64 is a lot faster with respect to input latency than any modern machine.
Or to switch from VSCode to SpeedScript
I've been a happy starship user for a few years at this point (after a long time with oh-my-zsh). For me, it's killer feature is the `starship.toml` file. Gone are the days of arcane bash escape sequences to style the prompt. It's a well-documented shape and easy to reason about. So no matter if you got maximalist or minimalist for your, it's easy to tweak. That rocks.
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.
I like the host you have that code on. That's refreshing to see a website that doesn't _require_ you to run some javascript.
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)
The `cmd_duration` starship module can additionally tell you how long the previous command took: https://starship.rs/config/#command-duration
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.
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.
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.
Tried it. Not a fan. I find it unnecessarily fancy.
Then customize it not to be. Are you criticizing it for having too many configuration options?
For a non-fancy prompt, setting PS1 is enough - no need to install anything.
If I have to do that I might as well maintain my current zsh config with antigen.
I criticized it because it's not "minimal" and it's not "blazing-fast".
I've been using it for awhile and love it:
https://github.com/iloveitaly/dotfiles/blob/master/.config/s...
My personal favourite: PS1="%~ $ "
I'm assuming that this is a zsh prompt string.
Yes, bash would be: PS1='\w \$ '
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.
text is discrete, graphical is continuous. very different psychologically. i disagree with you wholeheartedly.
What's a graphical shell in your mind if you don't mind me asking?
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.
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?
For Kitty I posted it on https://github.com/kovidgoyal/kitty/issues/8752, maybe we'll learn more!
Try tweaking kitty's input_delay setting. For example: kitty --override=input_delay=10
input_delay doesn't seem to address this in general: Even when set to 50 (which is very noticeable), the cursor on the next line just appears with some delay.
None of the settings from https://sw.kovidgoyal.net/kitty/performance/ seem to affect its appearance.
Interesting, In zsh I experienced the exact behavior you described and setting input_delay to 10 completely resolved it. To be fair, when testing my PS1 was simply '%m$ '.
I just benchmarked 'starship prompt' and when in a directory managed by git, it can take well over 10ms. I imagine with a more advanced configuration it would take even longer. urxvt must be doing something special.
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.
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.
I use Starship without any customizations and its good enough for my every day use.
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...
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.
Came here to ask the same. Long time ohmyzsh user, and wondering what new features / benefits Starship has.
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/LukasKnuth/dotfiles/blob/main/zsh/.config...
Basically it is quicker.
I also expect it has everything that you have in your prompt so is a direct replacement without losing anything.
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?
Can't find the URL again for a funny (and probably universal) custom prompt: you had to do some
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.
Happy user of spaceship prompt for zsh: https://spaceship-prompt.sh, and, among other things, it runs repo status asynchronously.
If you want to use Starship, but disable nerdfont and the language features leaving things like git, duration, error, etc., use this config: https://github.com/dannyfritz/dotfiles/blob/e53d410364bf6e2f...
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?
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.
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!
Per the Bash `history` manpage:
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.
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 :)
It's a different use case. If you run a slow command and check terminal later, you can see how long it took.
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)
/etc/zsh:
https://pastebin.com/kjwQ97z1
/etc/zshrc_Apple_Terminal:
https://pastebin.com/kfKF5ych
Fantastic, had no idea about these, cheers!
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
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.
I use oh-my-zsh which covers my needs well. Is starship 'faster' than that? If not, then I probably don't need much more than my default prompt:
I've used Starship for a few years with a pretty minimal config.
https://github.com/joeyagreco/dotfiles/blob/main/.config/sta...
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.
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.
Same here, that's what prompted my search. I felt I could get closest with oh-my-posh.
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.
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...
https://starship.rs/advanced-config/#transientprompt-in-powe...
Starship only supports this in PowerShell for whatever reason.
Edit: Doh. I see what you linked to now. Yea, maybe it does work in more than just PowerShell now?
Transient prompt basically removes your prompt decorations and replaces it with just `>` in your scroll back history in your shell sessions. In my case it's a slightly more complex transient prompt (datetime and exit code of the command), but still greatly simplified.
Makes cut-and-paste of history in to docs and stuff super nice.
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.
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
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.
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.
My earliest background as a shell user was as as system administrator (back in "the day", let's say), and forks are always potentially expensive, and often the reason you're opening a shell session in the first place (to diagnose resource contention or exhaustion, for example). There have been lots of times when one more fork is too much to take. (Which also, yes, makes it "interesting" to figure out what you can run in your shell session, too).
A non-forking prompt command is an absolute requirement for me and always has been, so I did this in pure shell. It's not a lot of code but it's a little tricksy.
If I still used bash, starship would be a non-starter for me, in part, since it's fork/execed in the prompt command. Further up this thread someone says that the zsh installation is different and it's a native shared library that gets loaded into zsh. That seems neat.
(The other reason it's a non-starter is that maybe I can stomach sending over a dotfile to various systems, but selecting a platform-specific native binary is too much configuration management to be done to prepare for an SSH session/kubectl exec. Eventually I made my peace with doing this for emacsclient so I could have local editing of remote files, but that's a lot less critical of a piece to miss than something that appears in your prompt. Conceptually, if you want to ship over/config-manage a native binary, you might as well install a better shell, which became a compelling argument to me when I switched to Powershell).
> 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.
Even 'git status' gets slow on large repositories (or slow hosts).
git status takes 643ms for github.com/rust-lang/rust
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.
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.
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).
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.
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.....
Powerlevel10k is perfect for me: fast, configurable, looks really good. It is not maintained anymore though :( I guess I'll keep using it while it lasts
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.
Agreed, you can replace them easily: https://github.com/LukasKnuth/dotfiles/blob/main/zsh/.config...
Too much bloat. If I want minimal, I’ll use a PS1 with 4 characters in it
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.
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.
I'm trying to understand what they are demonstrating with the "false; true" commands in the little video loop. Can someone chime in?
`true` returns exit code 0
`false` returns an exit code != 0
The prompt indicates whether the last command returned exit code 0.
Produced a 151 characters long prompt in my current development directory. This is really a starship, but I'm a pedestrian.
Well done for supporting windows cmd (through clink) ; most shell tools don't take care about us windows cmd users !
I'm impressed at how seriously they take "for any shell". It even works with cmd.exe!
i prefer powerlevel10K
Looks pretty nice, but the name seems unfortunate. (unless it crashes on every launch)
Warning: Improper use of Starship may cause it to explode in your test harness.
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;
Making a specific font a requirement is a bit too restrictive.
Starship + Ghostty has been an awesome (and fast) experience.
Atuin and Starship the same Day on place 1? Next zellij :)
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...
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...
Atuin was until it was bumped to page 2/3 and beyond :(
Is piping curl output to sh ever a good idea?
[dead]
It has support for fish shell... I'll pass.
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.
Fish shell detracts from people learning (and maintaining) to use POSIX compliant shell scripting. Professionals should be ready at a moments notice to use bash, zsh, and ksh. Also good to be familiar with a csh, (I would accept tcsh). Learn to use the tools of the trade, not toys.