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
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.
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).
> 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.
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).
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).
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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!
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:
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.
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.
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.
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.
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!
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
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'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.
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’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.
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.
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 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 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.
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 "#".
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.
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
╰────
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.
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.
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.
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.
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.
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'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.
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 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.
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 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)
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.
215 comments
[ 1.8 ms ] story [ 227 ms ] threadEDIT: 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
Of course the fastest thing is to just not stuff your prompt full of detail.
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.
git status takes 643ms for github.com/rust-lang/rust
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).
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.
My shell prompt is:
You don’t need an entire shell prompt customisation framework to be minimal.# clean, simple, minimal
I criticized it because it's not "minimal" and it's not "blazing-fast".
[right prompt docs] https://starship.rs/advanced-config/#enable-right-prompt [transient prompt docs] https://starship.rs/advanced-config/#transientprompt-and-tra...
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.
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.
Git-aware prompts can't be recommended on Windows, imo.
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.
https://github.com/mbachry/kitty-modeline
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!
Don't the layers of frameworks mean that the opposite is true.
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-ubuntuI 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.
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.
Even for cases where I need to use old versions, I don’t need a reminder of that every time I run a command.
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 example:
starship.toml:`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.
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.
Sort of contrary to that I really enjoy the maximalist shells. A computer should be fun to use!
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.
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.
What inspired me to work this way was this video on the acme editor: https://www.youtube.com/watch?v=dP1xVpMPn8M
tmux comes from BSD rather thsn GNU/Linux, or Windows
What is the default shell in OpenBSD
starship does not support it
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.
And the Branch is also an unintrusive reminder that you are in a path under versioncontrol.
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.
You can always time your commands with "time".
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
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.
Something like
really ought to be default in bash.It's not as clear why you need it in the interactive prompt.
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.
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 "#".
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.
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.
It would be nice to have a comparison and reasons to change from popular tools.
I also expect it has everything that you have in your prompt so is a direct replacement without losing anything.
1) I don't recall having a problem with prompt speed.
2) Are there any benchmarks?
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...
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.
Wondering if there are any other life-changing tools I'm missing out on...
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...
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.
ends up looking like this: https://github.com/bbkane/dotfiles/blob/master/zsh/README_im...
https://pastebin.com/kjwQ97z1
/etc/zshrc_Apple_Terminal:
https://pastebin.com/kfKF5ych
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