←back to thread

457 points benoitg | 6 comments | | HN request time: 0.415s | source | bottom
Show context
voidUpdate ◴[] No.44365306[source]
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

replies(5): >>44365338 #>>44365366 #>>44365392 #>>44365918 #>>44367891 #
1. danpalmer ◴[] No.44365366[source]
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.

replies(4): >>44365426 #>>44367421 #>>44367917 #>>44378423 #
2. blueflow ◴[] No.44365426[source]
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.
replies(1): >>44378330 #
3. account42 ◴[] No.44367421[source]
> 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.

4. WhyNotHugo ◴[] No.44367917[source]
Even 'git status' gets slow on large repositories (or slow hosts).

git status takes 643ms for github.com/rust-lang/rust

5. partdavid ◴[] No.44378330[source]
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).
6. partdavid ◴[] No.44378423[source]
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).