I use oh my zsh for exactly one reason: I can get a good shell experience out of the box and immediately start working on stuff productively, whether it's a new machine, a new remote host or a container.
I could spend hours figuring out all those things, bit I'd rather use that time for something more important.
Try https://starship.rs then. Starship gives you the same "drop in and go" experience but without the 200ms+ prompt lag. One curl -> one line in your rc file, works on zsh/bash/fish/whatever.
I'm so glad I switched to fish, I'd rather have genuinely good settings out of the box rather than endless configuration, and honestly it's much better out of the box than any configuration I've ever had.
Only drawback is that it's not POSIX, no issue for me, but maybe for people who have a lot of muscle memory with bash.
I tried fish for a while but as someone who heavily used bash before I couldn't get used to the new language. I also didn't feel they the language was much better than bash, at least for my usage. But I loved the default automatic coloring of arguments, underlining of files, etc.
Later I found fizsh, which I love and still use as default shell now. It's basically a configuration around zsh adding the colors, completions, and other good stuff inspired by fish to zsh. Can really recommend it for those who are used to zsh or bash but want their CLI to be more readable. Colors especially help with big command line arguments to show where they start and end, and keeping track of complex stuff like loops and conditional logic in your commands.
For POSIX: I leave Bash as the system shell and then shim into Fish only for interactive terminals. This works surprisingly well, and any POSIX env initialisation will be inherited. I very rarely need to do something complicated enough in the REPL of the terminal and can start a subshell if needed.
Fish is nicer to script in by far, and you can keep those isolated with shebang lines and still run Bash scripts (with a proper shebang line). The only thing that’s tricky is `source` and equivalents, but I don’t think I’ve ever needed this in my main shell and not a throw-away sub shell.
I often write multi-line commands in my zsh shell, like while-loops. The nice thing is that I can readily put them in a script if needed.
I guess that somewhat breaks with fish: either you use bash -c '...' from the start, or you adopt the fish syntax, which means you need to convert again when you switch to a (bash) script.
I guess my workflow for this is more fragmented. Either I’m prototyping a script (and edit and test it directly) or just need throwaway loop (in which case fish is nicer).
I also don’t trust myself to not screw up anything more complex than running a command on Bash, without the guard rails of something like shellcheck!
I used to do it this way, but then having the mentally switch from the one to the other became too much of a hassle. Since I realized I only had basic needs, zsh with incremental history search and the like was good enough.
I don't care for mile-long prompts displaying everything under the sun, so zsh is plenty fast.
After 10 years on zsh I finally switched 6 months ago and I haven't looked back. If I need POSIX, I'll just run scripts with the right shebang or pipe it to sh.
First, there are some ways to make fish more compatible with bash.
If you want to do some shell scripting in fish, or running other people's shell scripts (or commands) this may aid you since you wouldn't have to port them (or take less time to port them over).
You can achieve this with a plugin system such as 'oh my fish' or 'fisher'. But, as always, it adds complexity (and bloat :P), you'll need it on every fish shell (including remote systems), etc.
It is a bit akin to having nvim with plugins versus being able to use vi. Sometimes, you're going to need to be able to use the latter.
Also, to people who recently adopted fish: fish has been made more and more compatible with bash throughout those years.
The way I actually have things setup, in case it helps. I don't change my default shell. I actually default to pretty much working within tmux. So, I kept my default shell to what the OS brings, then in my tmux config, I have,
# set shell
set -g default-shell /opt/homebrew/bin/fish
This means, that when I start my terminal, it drops me to zsh (macOS default). Then when I run tmux, it opens fish. The nice thing is that I inherit the environment of zsh.
I have my .zshrc and my .bashrc sourcing a .shellrc file which contains most of my env stuff. This keeps random utilities that write to .bashrc and zshrc working within fish too.
Just tried Starship, even though it wasn't the first time I'd heard about it. I would not say it is a 'drop-in and go' experience. Let me explain.
After installing and adding it to my bashrc, I was wondering was those version numbers and cloud symbols meant. Turns out: Since NodeJS and Python were installed, it found a good idea to print the respective versions. I could not care less about those versions. The other part was that it thought that I would like to see my AWS region. Well, I mean, I have built something with AWS a few years back, and the config file for that still exists, but no, I don't want to see that region every time I open a shell. Finally, the default is to have the prompt in a new line. I think when you have a long prompt that makes sense, and it might also be a taste thing. However, the documentation has this example at the beginning about newlines:
# Inserts a blank line between shell prompts
add_newline = true
So I thought `add_newline = false` should do the trick, but it didn't.
Luckily, the AI (GPT-5.2) was pretty good at explaining and giving instructions for changing things. So after 30 minutes, everything was understood and configured to my liking. I like the result, but the default was pretty weird.
You can see that when the segments are empty, they still appear as a 1-width segment, rather than entirely disappearing.
It also makes you configure many things by hand. powerlevel10k has an interactive wizard that lets you design your prompt one option at a time (do you want a nerd font? do you want it one line or two? etc) but Starship makes you manually write escape codes if your preferences don't match one of the presets.
No judgment, but I do wonder what people like about Starship that makes up for these things.
Starship allows empty segments, I in this specific case it's just how the preset/theme works as it uses the Unicode character as separator and it needs to set the background and foreground colors depending on which modules is surrounded by
Every preset with powerlevel10k-style segments don't support hiding empty segments. Look at Pastel Powerline, Tokyo Night, Gruvbox Rainbow, Catppucin Powerline...
I tried making my own and the config TOML syntax isn't expressive enough to support hiding empty segments.
You're right that it's the thing with the Unicode character as separator, which all the alternatives handle just fine: powerlevel10k, tide, oh-my-posh... it's just everyone seems to love Starship, and that's what confuses me.
I tried using Starship, and it’s clearly faster than Oh My Zsh, but my issue was that I relied on some useful Oh My Zsh features that I didn’t know how to replicate in Starship. One of these is history filtering - for example, when I type source and press the up arrow, I only see previously run source commands, which makes it easy to find what I’m looking for. I tried to get this working in Starship, but had no luck.
I have never used Oh My Zsh, but I use Atuin to do this and it works excellently at that. You can even make it filter by what folder you're in and whether you want to search only this session or host (you can sync shell history across hosts). It never occurred to me that this is something I'd want from a shell prompt, which is what Starship is.
In case you weren't aware, MacOS uses zsh as the default installed shell. The bash version that comes with MacOS is some ancient 3.x version, from 2005.
Just that it would be `.zshrc` since zsh is already the default shell in the context of this post unless you enjoy a mid-2000s existence and none of the nice bash features of this generation (in which whatever `.bashrc` you've crafted is likely broken by time passing).
Maybe I'm underinformed, but I don't personally know any Linux users who convert to zsh, instead opting for fish or something else (oilsh? nushell?).
FWIW if you're on a machine where you're allowed to use non-default configs like oh-my-zsh, you could also just copy over your own custom config. It seems like you're implying the alternative to using oh-my-zsh is to rewrite your config from scratch every time or use the default. It doesn't quite add up to me. If you craft a config file of your liking one time, then back it up somewhere, track it with git, whatever, you can keep making use of that config across other machines. I just set up a new personal machine recently, grabbed my dotfiles, now it's the same familiar feeling as my other machine.
Crafting a custom config is right up on the list of things I enjoy. Right up there with creating new characters in video games that allow lots of customization.
I stopped using Oh My Zsh for exactly one reason too: It was so freaking slow it had a noticeable effect on my shell and my mood. It frustrated me that I had to stop and wait every time I opened a tab.
So I removed it, then continued using Zsh and whenever I missed something from before I looked up what it was and installed the plugin easily with Homebrew. The whole process took under an hour. I realised I only needed two or three plugins.
Now my shell is fast, without unnecessary bloat, and does what I need. I’m much more productive and happier, and at the end of the day I don’t really see what’s more important than that (within the scope of the conversation).
Exactly. The popular culture has bad picks. We can be low effort without necessarily being 100% unselective! No taste is not mandatory! Just the littlest bit of trying & listening to our peers can make a better world.
There's so many better non-shite alternatives. Just one: Zim aka zimfw is one. It's just so sad that there's such a negative creep energy towards "I tried nothing and did nothing and this is where I am". Bad hacker bad. You deserve no voice.
Less than five minutes to read but how long to set up my own? The author only showed what he needs/prefers ("Here is my config for starship"). I'll need to navigate the documentation of starship to figure out all those options, which defeats the purpose. Their config documentation (https://starship.rs/config/) already gives me headaches.
And from the article
> Because cloud services are available globally, I've disabled them.
That's some bad defaults right there.
> When you run a command, it also shows how long it took to execute.
No I absolutely don't want this thing done by the author. Now I am fully in the "customize my config" territory.
Also, most of us are unlike the author, and 0.07s vs 0.38s startup time means no difference.
I think the point of the previous comment has been more than clear enough.
> Also, most of us are unlike the author, and 0.07s vs 0.38s startup time means no difference.
That's quite likely a workflow thing. If you are popping up new (transient) terminals frequently, then a ~400ms wait time for each adds up and makes the entire machine feel really slow. I'm willing to wait extra half a second for a new terminal -- once -- after I've changed my autocompletion configs (rebuild + rehash takes a while), but if I had to wait for that long every time I hit Win+enter and wait for the terminal to become active, I'd be irritated pretty damn quickly too.
You get conditioned to immediate responses pretty fast.
Can you spoil it for me, because I read it to the end and saw no mention of such a project. Unless you are referring to the DIY approach the article suggests.
That misses the point. I don’t even want to think about any of that stuff.
It’s a single command to install oh-my-zsh. I can fire it off, check Slack, and come back in 5 minutes. If I have to take 5 minutes to setup it up, I’m just not going to do it.
This is common low-quality internet arguing ("you care enough to come into this thread but..."). You can avoid this by keeping in mind that different things are different things, and analogies have many holes by default.
Their point is that what you complain about as "time consuming" is not time consuming at all and that you consumed more time reading the post and commenting on HN that actually installing starship.
In your defense I must say I installed starship ages ago but still not migrated to it from powerline-go because I'm lazy.
Some chefs like to spend hours sharpening their knifes with wet stones. Others are just going to run it through a power sharpener and get on their way.
I like to focus my craft in places other than the terminal.
Different strokes I guess. Personally I think any time spent tinkering with the shell is a waste of time: a basic, zero-customization bash is just as good at doing things for me as a shell that I've messed around with the settings on for ages. So I don't waste time on customizing my shell because it provides no value to me, while those who get value can spend the time. We both win.
there's some nuance to this. people might want to spend minimal time hacking on their shell and more time hacking on things they find interesting that are not related to shell setup (and also not webshit). besides even if its webshit, what makes you say shell setup hacking is more or less interesting compared to webshit hacking. the term webshit itself implies you view it as less interesting than shell setup -- fair if thats your pov, but doesnt make it intrinsic.
It’s more that tired experience has taught that of the various disciplines, web devs are the most likely to have a shaky-at-best understanding of fundamentals, and thus do silly things like assume network calls will never fail, or store everything in JSON blobs and then wonder why their queries are slow.
I’ve also worked with some awesome web devs, to be fair.
Hacker News: Where the hackers don't want to think about the code required to build the webshit nor the command-line nonsense used to write it, because the agents will take care of all that.
I will have forgotten almost everything by the time something inevitably breaks in a few years. Unless I am constantly recalling the knowledge and applying it, I don't find it worth it. And I _don't_ want to be constantly recalling this knowledge. I want it to just work.
OMZ has been working steadily for me for the past 8+ years. Autocomplete, syntax highlighting, and a concise prompt--really all I need.
I've spent few days and got some basic zsh settings adjust for me. Since then I'm mostly using zsh with very little configuration and I like it a lot. Yes, it's a steep curve, but I'm spending all my life in zsh, so I think that was good time investment for me. In my experience default zsh settings are good enough and require very little customization.
This is the most common complaint I see for switching interactive shells to fish/nushell, but it's not a problem in practice. You don't ever uninstall bash, so if you've got a command to paste:
I recreated my several hundred line + several plugins zsh config in a few dozen lines of fish and one plugin (fzf.fish), about 8 years ago. It’s been a joy to use.
Exactly why I switched to fish. Fish doesn't come preconfigured exactly how I would like, but it's close enough that I just grew accustomed to fish defaults and have no trouble with it now, and no longer give any thought to shell configuration.
The additional upside of this approach is that you can also quite easily install fish on any host and it won't need any configuration to match what you're already used to
Totally agree. Fish out of the box is super performant, lots of tools ship completions for it, and the UX is just great. Only recommendation for people new to fish is to read the keybinds thoroughly. I convinced an eng on my team to switch but he was using it like sh: not using tab complete, shift+arrows for partial complete, etc. Slowed him down a ton.
> For Vim users, I also suggest enabling Vim mode in Zsh. It makes editing commands much faster.
I am also an avid Vim user but I disagree. The default readline is perfectly fine for single line commands (you do have to know your way around some basic commands though C-a/u/k/l/w...). To edit long commands in $EDITOR you can always do C-x C-e in bash/zsh (M-v in Fish). As a matter of fact everytime I pair program with my colleague I always think he is editing those short commands slower than I would have because he has to change modes all the time.
I like to re-add the readline binds after enabling vim mode, and then I only leave insert mode occasionally. C-x C-e really is great, though, I think I do tend to reach for that if I need to do a big edit of a one-liner.
Changing modes is a single key stroke away. That's hardly a reason to be slow.
Readline settings depend on what you're already used to. If you're comfortable with vi key bindings, then being in normal mode, navigating with `w`/`b`, deleting a word with `dw`, deleting up to a quote with `dt"`, etc., are all done with muscle memory, and should be much faster than learning the equivalent Emacs bindings, pressing unintuitive key chords, or opening the command in an editor. I don't like opening an editor since it's an interruption, and it hides the output of the previous command.
I wish I could have the full power of Vim in my shells. For example, I miss the delete between characters binding. `di"` or `di'` are great for modifying argument values.
Like many other people, I use oh-my-zsh for default setup and that's it. I literally use a single plugin for git and very actively autoload my custom functions to avoid startup delay. With my 384 line config and oh-my-zsh on, here are the results:
For anyone who cares about zsh startup performance, `zsh4humans` by `romkatv` (author of powerlevel10k) is worth a look: https://github.com/romkatv/zsh4humans
It achieves instant startup by rendering the prompt before the full shell initializes. Since adopting it, I am done fiddling with my shell config and the fact that `zsh4humans` is in maintenance-mode is actually an advantage as it keeps me from wasting time refactoring `zshrc`.
I think `zsh -l` start a login shell, which does not load zshrc so oh-my-zsh don't get initialized. Try `zsh -ic exit` and it should load zshrc before executing exit.
Valid points, I learned something new today. Thanks, you were right. If using -ic flags I am getting around 300 ms... Interesting how I never noticed, guess I don't open many terminal during the day
I switched to fish shell with star ship. Fish has autocomplete and syntax highlighting out of the box which is quite neat and the main features I use in omgzh so fish was a safe choice for me
Fish is also not POSIX which has always been its, and my, issue. I use zsh+starship and my own very minimal init stuff+zsh autocomplete and syntaxhighlihg plugins. It’s not a perfect setup. I wish fish would “just work” but it doesn’t. Frequently I had to look up for “workarounds” for my setup. 25 years in, I think I got it and i just keep my zshrc and `machine-init.sh` on point for my-own-style-experience. I think a lot of that could be simplified with fish+starship, but it’s just not there.
> Fish is also not POSIX which has always been its, and my, issue
Could you give some examples of issues you encountered because of that? I've been using fish for about 8 years now I can't remember an instance where that was a problem in interactive use.
Same here. More than 5 years with fish and it’s been like 5 times when not-POSIX was an “issue”, which I’ve been solving by temporarily entering bash and rerunning the command there.
Issue is the cognitive overhead to know 2 distinct shell languages. One you use, and one (almost) everyone else uses. If later isn't of your concern and Fish is all you interact with then no issue whatsoever for interactive or/and scripting use.
Not to be funny, but is POSIX scripting even still relevant? It's well understood that they should only be used for quick and simple tasks, and anything more serious or demanding should be done using something like python instead. But these quick and dirty tasks are very easy for LLM coding agents to do in python. I used to have dozens of shell scripts, each no more than tens of lines long, in my ~/bin/, but I had an LLM rewrite all of them in python, adding proper argument handling, --help messages and error handling too in the process. I sincerely don't think I'll ever write another bash script again.
Do you know how many CI/CD pipelines run on shell scripts?
Another example is small utilities. I wrote one to login to MySQL DBs at work. We have to use Teleport, which I dislike, and it has MFA. So I made a small SQLite DB that has cluster names, endpoints, and secret ARNs (no actual secrets, only metadata), and then wrote a shell function that uses fzf to parse the SQLite DB contents, then ssh tunnels through an EC2 with Teleport to the selected MySQL DB, using expect with a call to 1Pass to answer the password request, and then picks the first available port >=6033 to connect the mysql client. It also tracks the MySQL DB : port assignments in the SQLite DB and waits for the client to exit so it can tear down the ssh tunnel. The only input I have to do beyond selecting the DB is answering a push notification on my phone for MFA.
> replacing 10-LOC shell scripts with Python
The startup time would drive me insane. I love Python, but it’s not great for stuff like that, IMO.
For me it’s always been an inability to “copy this command from stackoverflow” (or in the modern day, it’ll be copy this from ChatGPT) into your shell. Maybe it’s better now, but the last time I seriously gave fish a chance was 2014.
Also one of may main use case is documenting things other developers can do to make their life easier. There are handful of things where zsh behaves differently than bash. And while those handful of thins are not even a POSIX or shell things, they often come up.
The reality is, every day I’m fighting with “developers” who don’t know what the difference between AWS, Linux, and bash is. Throwing “fish” into the mix seems like I’m just being obtuse for no reason. I have sept hours trying to explain to some dumbass that git-bash on windows is not the same thing as Linux only for them to call me “oh he really cares about ‘bash’”-guy. While claiming they are “Linux developers” as they use macOS.
I confess I don't really get this. Fish and Bash are different languages in the same way that Ruby and Perl are different languages. And if I want to run a Perl script, I don't try to run it in a Ruby interpreter, and I don't get grumpy at Ruby for not being source-compatible with Perl.
Which is to say, if you need to run a Bash script, run it via `bash foo.sh` rather than `./foo.sh`. There's no need to limit yourself to a worse shell just because there exist some scripts out there written in that shell's language.
There's nothing even preventing the second form from working either. Just put the right shebang at the top of the script and it'll run through that interpreter. I've been on fish for a decade, but still write all my shell scripts in Bash. It's never been an issue.
Yeah. I used zsh for decades, invested a reasonable amount of emotion and time in my config but swapped to fish last year as a sort of January trial and it stuck.
It's not perfect, the lack of HEREDOCs are annoying sometimes, and no background-able blocks (eg `{x}&`) means you can't async things as easily in scripts.
Zsh has a lot of advanced stuff (at least for a shell) that can deliver pretty complex scripting such as throw/catching, mountains of variable flags and switches which I do miss when I write fish scripts but really -- I've abused them a lot over the years and now days I would be more likely to just use a "builds to a single binary" language.
I will probably swap to nushell when it gets a bit more stable (in my experience it's runtime is stable, but it's feature set / command names are still shaking out. I really like it's general ideas though in terms operating on structured data.
I switched to zim years ago and found it has all the features that I need but is much faster and I think easier to install (though I haven’t installed either for some time).
Fast as sin, and one of the most flexible installers systems. You can point it at an incredibly diverse array of different things to install, in different forms, with different urls, and it will just do the thing.
Zimfw definitely has it's own ecosystem, plugins which are zimfw capable. But it's remarkably versatile at bringing in zsh code. Most plugin-systems are pretty ego-centric, demand specific implementations, and zimfw stands out not just for it's ridiculously impressive speed & handling, but for it's versatility too.
I installed oh-my-zsh back in early college some 15 years ago, before zsh was even the default on macs, and it is so good I’ve never felt compelled to experiment or try any other shells terminals or configs. It’s the first thing I install on every new computer.
> The main problem with Oh My Zsh is that it adds a lot of unnecessary bloat that affects shell startup time.
Wowsers!
That +0.5 seconds delay will kill cats everywhere. We must microoptimise the startup time of shells!!!
Or ... we could simply use bash and KDE konsole with, say, 10 tabs. That setup works for me since ages; admittedly I use bash just as a wrapper for simple actions as well as calling a gazillion of aliases and mostly ruby scripts that do the real job. But damn I never knew there were guys who were concerned with +0.5 seconds delays caused by oh-my-zsh. The bloat! Oh my godsers!
For terminal-centric workflows, one ends up needing to open dozens of shells throughout the day.
Starting one command, realizing you need info from a previous command, often the fastest way to get that info is to open another terminal and start typing and the copy-pasting the relevant piece of cmd. Or needing the output from another command that's scrolled up in a window. In general you end up with a mosaic of tiles each of which is holding key information. So you inevitably open a new tab to make use of the information in the other 3 or 4 windows.
Shell startup is mainly not about waiting for a few terminals in abstraction, but about the way each shell is just a small piece of a longer live workflow and waiting a second for a shell so that you can fill in a piece of a command feels terrible. I think nushell will help cut down on this unpiped inefficiency, but it's usually much simpler to manually glue bash commands together than to parse text output and pipe.
I couldn’t help but think this as well. I understand wanting software that feels snappy, but this is hardly a problem. Instead of trying to convince the reader that we should care about this, it would be nice if the writer admitted this is an inconsequential personal preference.
Plus, how many shell can one individual open in a day ? I'm doing that once per day on a good day, maybe twenty if I have a lot of unplanned work on subprojects that needs to be done concurrently with my main task.
Sometimes hundreds per day. Tabs come and go here. People have different workflows.
Yesterday just shy over 50, according to entries from `login` in the system log.
I do launch multiple interpreters just to get a fancy coloful cowsay on each launch. Which involves the fortune program, lolcat (via ruby) and cowsay itself (via Perl). I probably should optimise that into a single C binary for better startup times! :)
The problem with long startups is that they break the flow. I live in CLI. I open and close terminal windows all day long, sometimes just for quick 2-3 commands to check something. 100 new interactive shells a day is my guess. I already know commands to run, my fingers are ready to type, they already pressed the keys ti spawn a new shell and now they have to stop for 500 ms. Repeat these 100 interruptions every day and you get the death by 1000 spoons.
I don't use oh my zsh, but on one laptop zsh took 600ms to start. I narrowed it down to a strange "bug": adding even a single empty file to the custom fpath caused the slowdown. It bugged me so bad that I decided to try fish again, but this time for real. And this time it stuck with me. I like its architecture (defining functions to change its look-and-feel - great idea!) and of course its 32 ms startup time.
As another commenter, I'm probably at 100s per day.
A reason is that I use i3 workspaces, with each workspace being for different tasks, so I don't want to reuse a terminal that has another context.
One issue with keeping a single shell is that the history is full of irrelevant stuff. If you run commands that take a while and print a lot of output, you want it to be as clean as possible. If I want the beginning of the command, I can scroll to the top, and I don't end up with some unrelated output.
I also take quite notes in vim everywhere, often next to long-running commands, using tmux.
I have 90 lines zsh config with 3 plugins (compinit, vcs-info, edit-command-line) and startup-exit sequence takes 0.32s.
You learn very quickly where the lags come though when you work on a big old repository (I learned this on Emacs source code) where getting current branch for jujutsu takes ~5 second. Git is faster in this regard but it still is ~0.3s
I'm not fan of starship (I don't use fancy command line variables in general) but many of those issues can be dealt with awesome bkt caching utility [0]. Instead of live reading just let bkt cache it with long TTL with eager async refreshes. My guess is that Starship does exactly that.
When I switched to zsh 5 years ago, I went with a stock set up too.
There's quite a few things the OP's post didn't mention about shell history that I think are really important:
setopt HIST_IGNORE_ALL_DUPS # Never add duplicate entries.
setopt HIST_IGNORE_SPACE # Ignore commands that start with a space.
setopt HIST_REDUCE_BLANKS # Remove unnecessary blank lines.
It's possible to roll your own prompt that does helpful things without using starship.
Also you can roll your own zsh plugin manager in a few lines of shell scripts, `fast-syntax-highlighting` is a really useful plugin to get real-time feedback when typing commands.
Most of those things are mentioned here https://nickjanetakis.com/blog/i-recently-switched-to-zsh-an..., the post is 5 years old but just about all of that is what I do today still. Since then it has evolved to become better IMO, including using a dedicated Vim zsh plugin which is much improved over the default zsh key binds. Also another plugin to show zsh's tab complete in fzf instead of zsh's window. The tab complete demo video is here https://nickjanetakis.com/blog/hooking-up-fzf-with-zsh-tab-c....
I moved from oh-my-zsh to grml ~10 years ago, and I've enjoyed it - it's got good defaults, is extensible (I've added custom stuff to handle how I manage directories for work things) and the single-file nature of the defaults makes it super straightforward to put it onto a new machine (ie a server) without then necessarily needing to do any extra tweaking
I use a subset of omz by cloning it and manually sourcing the plugins I want myself rather than initializing the entire omz system. No themes, no checking for updates, etc. For me, it’s the best of both worlds.
After holding out for literally years after Mac changed their default shell to ZSH, I finally switched over. I didn't love it, but it was okay and had some niceties that I wasn't used to. Then I started to configure it and inevitably ran into Oh My Zsh, and spent some time playing around with that to get it how I liked.
In the end, I realised nothing was as good (to me) as my original Bash set up. I have all the features I need, it's universally supported, and it's fast.
I use OMZ because it lets me rely on popular defaults instead of bike shedding and rolling my own. Its main advantage is convention over configuration. For instance, I just have to learn the git plugin aliases once, and then I can use them anywhere with OMZ + git plugin. Is there any lighter alternative that is compatible with OMZ plugins?
I had the same gripe as the author. OhmyZSH seems too bloated for my needs. Added to that, the defaults adds (and oft unnecessary) emojis to prompts & outputs - something I don't find tasteful or appealing.
I stripped out most of the OhMyZsh functions (which is pretty modular given a shell package) and created a smaller, leaner package (leanZSH) having only the known stuff I may use. I have been using it without much complaints.
In a similar vein, there is slimzsh [1]. For me, it is a minimal config that enables everything that's useful, and only that. Quite a few others and I have been using this for more than a decade.
https://github.com/changs/slimzsh
The amount of time this author is complaining about is like, a fraction of the time I spend getting through the first few sips of coffee in my day. I'm sure there's so many bigger time optimizations to tackle first.
What workflow involves opening hundreds of shells every day? Like, I've got a half dozen shells open at any given time, and sometimes I gotta refresh or reboot, but even on my worst day in looking at two dozen.
Temporary splits to run code close to the editor, tmux popups (they open lazygit or file manager on top of the current tab). Debug runs, where I want to preserve their output for some time, so I keep them in separate tabs.
I use a lot of short-lived terminals. I have zsh+foot configured so that ctrl+shift+n opens a new terminal with the same current directory, so when using Vim, that's as fast as putting Vim in background, but I can tile both windows easily.
I never have more than a one or two dozen terminals at a time, but I definitely open hundred of short-lived ones.
For command search I've replaced regular search and fzf with atuin. Works especially well with multiple hosts.. https://atuin.sh/
EDIT: The OP fails to mention zsh profiling: zprof. I discovered that atuin is my biggest waster at the moment with like 20ms and rest of the stuff I could clean up.
I use atuin for the shell history as it seems to know when I've run a command in one tab/split while another is open where fzf doesn't seem to sync it all the time. But I still use fzf to find files.
(Bonus, I use Zoxide to replace the alt+d cd shortcut as it's much faster, and use https://github.com/Aloxaf/fzf-tab for tab completions in the terminal to become fuzzy, very very useful)
>it seems to know when I've run a command in one tab/split while another is open where fzf doesn't seem to sync it all the time.
On my machine this is handled in zsh, not fzf (but then fzf still benefits). You can configure your shells to sync without exiting. You may need to run one command (or just hit enter with nothing typed, maybe) for the shell history to catch up, but then it should all be there. Relevant options:
# share history among terminals
setopt share_history
# append to the history instead of overwriting
setopt append_history
# append to history incrementally instead of when the shell exits
setopt inc_append_history
I think finding out about this is why I originally switched from bash to zsh several years ago.
Atuin also has syncing and backups though I've never really felt the need to use it. I prefer keeping histories separate and when I need to share shell commands I just do the usual methods like putting it in a shared text file, send it to myself on a chat app or just looking at the command and typing it out
Yeah. It boils down to preferences. By the way, there is also an option to search only in current host and current directory as well (+current session).
They complain about a startup time of 380ms, but with the default configuration it's only 60ms on my laptop. That's faster than the final startup time of 70ms of their custom config, and it has all the features that they added to their config. So with all the features they need OMZ should be fast enough for them? I don't get it.
I tries oh my zsh whil switching to it from fish ("the we don't believe in configuration" shell). I thought it would be great with all the popularity it has but 90 percent of the plug-ins are alias definitions which I certainly won't memorize somebody else's. Just found a few plugins I like for the fish functionality I liked. Spent some time configuring it asking for help on the irc channel for zsh when needed. Great people. Zsh is awesome. No plugin manager for me though. Thanks.
I never moved to omz (or even zsh; I still rock bash) because I have 10+ years of dotfiles that cover all of my needs. I can see all of the cloud accounts I'm logged into, the status of my Git repositories when I'm cd'ed into them, the number of directories deep my stack is when I use pushd, and have lots and lots of custom functions that save me time. I had moving to zsh in my personal backlog for many years but have yet to come across a pressing reason why I should!
Anyway, yeah, all of this adds startup and command invocation time, but the value far outweighs the latency.
I'm changing to GhosTTY as we speak (from Mac Terminal, because I'm tired of gemini-cli not getting my shift-return for newlines). Wasn't until that process that I learned that new Mac accounts are on a different shell (zsh) than I have (bash). Last time I switched shells was when Apple flipped from tcsh.
Now, I'm deep down the rabbit hole of standardizing all my shells/terminals/configs with Nix. Either a really good or really bad project to start on a Friday night.
It's basically the same, except smarter about command history and auto-completion by default. I'm sure you could get Bash to act the same way with a bit of prodding.
I don't think 0.38s is a bad trade-off for convenience when the rest of the tools I need to do my job collectively are another 2s at shell startup. NVM alone adds 0.5-0.6s on my M4 Macbook Air.
You can replace nvm with https://mise.jdx.dev/ , it starts effectively instantly and works not only for node versions but all programming languages and tools.
Mise started out using the same plugins as asdf, mostly focused on adding performance and usability improvements. Over time it added more features and security.
Most tools are now directly fetched from github releases without the need for random shell scripts (which is what asdf plugins are).
It also grew to be a task runner and environment manager. At first you might think this is scope creep but they're both opt in and very elegant additions. I don't want to ramble but let's just say they've solved real problems I've had.
I'm a fan of it, and I can't think of a reason why I would use asdf over mise. Its real competition is nix (+devbox/devenv/flox), devcontainers, and pixi.
mise has more features - it is a super set of asdf. For example it can set your env vars when you cd into a directory (like direnv). It also has tasks (which I haven't used) - they appear to be similar to what a Makefile does. So you can potentially replace three tools (asdf, direnv, make) with one.
I am seeing a phenomenon of people wanting to hyper optimise their workflows. It’s nonsensical when you consider the other stuff you need to do or how slow everything else is.
Holy heck, I just profiled my zsh initialization and nvm was the big source of bloat, holy hell. Similar setup as you (M4 MBP), same amount of startup bloat. Lazy loading it fixes it.
Although this is what Opus recommends, it will give you many issues as you don’t really have any node runtimes in the path (or worse if you do).
What I recommend is replacing it with $PATH=(a command to find the nvm default alias directory, detect the verion and load it from that specific version directory directly) so you always have default node in path and then lazy loading only nvm itself, so you can switch when you need to.
Sorry I don’t have the command handy as I’m on mobile but if you paste the above into Opus you’ll get it.
FWIW, I still use bash as well. Nothing against zsh per-se, it's just that I know bash, bash works, and there's no particular pain I experience using bash that will obviously be solved by switching. And when you factor in anticipated switching costs, I haven't found any compelling reason to spend any significant time on zsh so far.
Yes, I'll throw my hat into this group too. Bash is fine.
YMMV but I have found using zsh too frictitious to be helpful. Sure, theoretically zsh living in a bash world (lets face it, all scripts are bash) is completely fine but reality seems to differ. Copied a one liner from shell history into your script? Crash. Use arrays? Weird bugs. Use shell builtins? Whoa unexpected interactivity!!! Etc...
Bash is absolutely fine as a default shell. As an added benefit, you don't feel like an invalid once logged in to a container or server.
I've been using it for the last 6 or 7 years and I can only remember one specific feature I use a lot: "unset HISTFILE" to disable history when I need to run commands with passwords.
Other than that, oh-my-zsh with git, systemd, and fzf plugins. Saves a lot of typing.
The main selling point for me is how easy it is to setup.
I don't think it is crazy, but I know and love the bash quirks. I've got permanent history setup thanks to Eli Bandersky [1] which I know zsh has a solution to already. But what annoys me with zsh is some of the ways it tab completes when navigating the filesystem, and not by default allowing comments on the command line, e.g. '# github api key blahblahblah', which I can then pull later using phgrep.
Slight pain on a mac to get the latest version and use it as terminal shell, but it gets easier everytime I work on a fresh mac.
If you want vi history editing like you are used to in bash for the last 20 years it's subtly different in a manner that makes it insanity inducing. If you use the traditional emacs like editing it's much the same.
Seriously. I do think people should spend enough time with bash or posix sh to be comfortable with it, but I'd recommend everyone at least just try fish. It's a lovely interactive experience out of the box with colors, completions, a great prompt, etc. Plus, the scripting language is quite comfy. Like, somewhere between bash and Python (if you find Python comfy, I guess). At least to me it makes more intuitive sense, once I got over the fact that "it's not bash/zsh."
It's written in Rust, if you care about that sort of thing (I switched before that was a thing). And for simple one-liners, compatibility actually has improved at least a bit (like you can do && now, which wasn't a thing before).
Write your shell-specific helper scripts or personal scripts in fish, write your portable scripts in Python or Bash. Look, I love standards. Sometimes non-standard things make sense though. Sometimes they even make more sense in the right context.
Or maybe you'll hate it. That's fine. People won't know until they try though.
For something newer and even more different, check out nushell. I don't have much experience with it, but a lot of its ideas are enticing.
Glad to see fish getting some shout outs here. Been using it for over ten years now, and it is super easy to get going on new hosts - it is just one simple install away.
The problem is that I forgot (if I ever knew) bash.
I can write fish, scripting or interactively on my shell without thinking too hard about the syntax, but when scripting in bash I require an example or using my snippets to be sure I'm not shooting myself on the foot or writing something that bash will reject right away.
The trick is to use "shellcheck" on your bash scripts, it's an overly anal linter that'll keep you sharp, and it's 2026, everyone can script bash with AI :)
But yeah the syntax with [[, if fi, while stmt; do; done, "$@", case esac, "${!VAR}" and others makes me long for the day fish shell gets "euo pipefail" mode so I can stop writing bash or || true :)
I think the last time that errexit and pipefail were brought up to the fish devs, we were treated instead to an essay about how errexit is a total hack in bash, how it has all kinds of places where it doesn't work as expected, how it's special-cased away for some constructs, etc. None of which is wrong, but it's still a whole lot better than the nothing that we have with fish now.
So we still have this inflection point where scripts eventually have to graduate into a "real" language, and while those languages give us proper data types and structures on one hand, they take away conveniences like pipes with the other. It's 2026, and we managed to crack artificial freakin' intelligence before we got a decently evolved shell into the mainstream. </yells-at-cloud>
Current branch without bloat is to cat .git/HEAD, and if that didn't exist, run git symbolic-ref HEAD. The first is faster and works in the common case where you're in the top of a git repo. In either case, run it through ${branch##*/} to strip down to just the current branch.
I have used this for a long time, never understood how people would put all of git in between them and the next prompt.
Oh My Zsh adds bloat but sets sensible default settings compared to vanilla zsh.
I tried using zsh without OMZ and I realized how many things are in OMZ which I took for granted, especially keybindings.
~150ms with minimal setup is good enough for me, although I would prefer <50ms.
huh, is this a problem people really have? I just have a plugin that lets me type before zsh loads and I don't really have a problem with this, even before that i didn't really notice a problem since my 'default' configuration is .12s.
time zsh -i -c exit
zsh -i -c exit 0.12s user 0.09s system 81% cpu 0.276 total
~
Surprised no one has shout out zsh4humans, perhaps because it's basically in maintenance mode but it's not like I need any new features. Love the ssh teleport feature.
I used Oh My Zsh for years, but there were literally 3-4 features I relied on: autocompletion, git plugin, history search, and one theme.
For some reason it was slow to load which I found annoying, so I used Claude Code to optimize it. In the end I ended up removing Oh My ZSH entirely, now I have a single .zshrc file that contains everything, and it became much faster.
Similarly I moved from Packer to Lazy.nvim and updated a number of libraries, and from iTerm to Ghostty, Claude Code essentially converted my configs in a matter of minutes
I have a script for each of my projects that I run when I open a new terminal window (Alacritty). The scripts set up tmux with 3-8 terminals, each terminal launches a components, utility or just sits in a folder from which I later run commands.
Having said that, I use only a few zsh plugins, and have a theme configured to not run commands that add extra latency.
This is acceptable, maybe the zsh-autocomplete is the problem for author or something else?
I originally switched to ZSH + Oh My Shell because it opens so fast. Ideally plugins would initialize asynchronously but it's not very easy with shell scripts I think.
I concur. I tried oh my zsh and for a while I thought I was doing something wrong. My experience was terrible. But it turns out that many people did not mind the bloat and the prompt lag. It was not for me. I uninstalled it and I have such a bad taste in my mouth that I am very reluctant to try any of the alternatives.
Yes! The very famous xz hack was only found, because a German wondered why his ssh session lagged 200 ms at the start. Everyone should go mad when their main tool lags a few hundred milliseconds. It is unacceptable that we sit on machines, that run billions of calculations per second and our software still lags.
Yes, and hundreds of developers just spent 5 minutes reading about it.
This investment makes sense for OP who opens hundreds of terminal sessions, but does it make sense to bother about 1s delay when they start the terminal session once in a while? I have several sessions opened all the time, the last time I wasted my 1s on zsh was in 2025 when I rebooted my machine due to a nvidia drivers update.
I have given up on any external bash configurator a long time ago, instead I write my own bash prompts these days, they lack a lot of functionalities but I am much happy with them for now, also a shameless plug:
https://martianlantern.github.io/2025/11/updating-my-bash-pr...
I have been using OMZ for the last 8 years but recently made the switch to plain zsh with :
- starship for a better prompt
- Claude ported plugins I was using from omz (extract, sudo)
- custom written aliases that were muscle memory
- zoxide for the a command
So far that has been a great move, my terminal tab feel snappy again. One thing I miss (but I’m sure I could find a way to replace it) is `cd ….´
The problem with zsh, as with a lot of open source tools is bad defaults. If only zsh had a better out of the box experience then OMZ wouldn't be needed. I used maintain a lot of configs, over 10 years I just keep forgetting what did I set up. I don't want to be bothered with this anymore.
Like many I installed omz and ran it as the default for a long time. After a while I looked to optimize my shell starts and realized I was only using a fraction of the functionality.
So I figured out what I was using and created my own very paired down version of what I needed. My boot times are much faster and I’ve been totally happy with it. I also learned a lot more about shell configs as a result.
It's funny how there are operations so sensitive to latency that even half a second feels too long.
However I agree with other comments that the author's baseline of 380ms is suspicious. I get 150ms (full config, 6 plugins) vs 50ms with no config and plugins.
I agree, I used omz a while now but I have since also realised that the features I uses are so basic, it really does not warrant a whole software project as a dependency.
So I went and had Gemini make me a zsh config with the features I actually use. Took 15 minutes to get all the autocompelte, aliases and search functionality and done.
I have a fast machine, never noticed a difference in shell start up time between with and without and given how much more pleasant it is with I'll take the hit.
Had this problem awhile ago of my zsh startup being slow. Just opened claude code and told it to benchmark my shell start and then optimize it. Took like 5 minutes and now it's ultra fast. Hardly any idea what it did exactly but worked great.
I had my phase of having a fancy shell with all bells and whistles. I’ve now settled with the default terminal so that 1. It is fast, 2. Whereever I work, I have the same experience.
I have not a small number of plugins on fish and I've never noticed a problem with startup time. I do wish there was a better way of managing or installing plugins. It just feels so fragile.
CachyOS is basically arch on easy mode. I used to spend countless hours tinkering with arch but then I got older and don’t have much time. Plus there are helpful meta packages for gaming that work great out of the box, which for a gamer like me sans Windows is pretty awesome.
I've tinkered at most an hour on my arch install and it's just been running smoothly. The installer these days is easy to go through as well. It's the same for bash, very little customization, then it runs smoothly for years.
I'm not saying CachyOS is bad, just that it is in my opinion another layer of complexity that may change/deprecate/etc.
That’s fair, the more steps you take away from the source distribution, the more variances become a potential for trouble. Also it’s been over a decade since I used arch, it’s probably a whole lot better now.
>I used to spend countless hours tinkering with arch but then I got older and don’t have much time.
Have your lost your old configs that you worked hard on? That's a shame if so. I love moving my configs I've worked hard on to new machines and instantly getting up and running in a now-familiar environment. It saves so much time and effort.
I was annoyed by this enough that I ended up cloning the OMZ repository locally, and stripping out all the modules I don’t use. And now I just have it as part of my dotfiles[1].
It's just a handful of files and I manually source them in my zshrc[2]:
It's essentially the same as omz setup I was using before, but loads in just ~25ms (Note: it's on a hard drive, with ddr3 ram and 18ms out of that is spent by compinit)
It also fixed another issue I had with Oh-My-Zsh: whenever they (very rarely) tweak their default config - it breaks my muscle memory.
I switched to Prezto because of how slow OMZ is, been really happy with it. At one point it started causing issues with the IntelliJ environment reader but it’s been perfect once I sorted that out.
> My workflows involve opening and closing up to hundreds of terminal or tmux tabs a day. I do everything from the terminal. Just imagine that opening a new tab in a text editor would take half a second every time.
This sounds like overoptimization on a neglible time loss for what is essentially an unique (and dare I say: broken?) workflow.
I use terminals a lot ... but I work with 4-5 day-persistent terminals that I open once a day and keep in the background. The QoL effects of omz outweigh microtuning startup times significantly.
Well yeah, you need antibody https://getantibody.github.io/ and then whatever plugins you desire. Been using it for years and it's never been anything other than fast and reliable.
I mean it's not like I've done any formal benchmarks but like I've used a bunch of plug-in managers and antidote, sorry antibody is the old one, it's just so much faster than all the others.
I may not need this sort of shell bling. And I don't use it. But my first Unix system was an early version of Xenix, which had the original Bourne shell that didn't even support cursor up to get a previous command. (I do use cursor up, C-r, and the shell editing commands.)
But yesterday's conveniences become today's essentials, and those who came in after me have their expectations set by the much more sophisticated things available at the time. Like, I'm still flabbergasted by people—working professionals—who go "I can't program without syntax highlighting, autocomplete, and my IDE generally going bing bing wahoo at me as I work, and I don't know how anybody can." We just type the code in. Like we all had to back in the day.
Anyway I can certainly see where someone younger than about 35, or who came to Linux late, would be completely at sixes and sevens without their colorized racing-stripes shell prompt.
Prezto is faster than OMZ, and has been for over a decade. Starship is faster still. I switched from using Prezto standalone to using Prezto + Starship and relying primarily on Starship several years ago. I'd be surprised if many people are still using Oh My ZSH in 2026 vs using Prezto, anyway.
This thread feels so foreign to me. I use basic ass vanilla Windows terminal. It’s fine. I also use the vanilla built-in to VSCode terminal. It is also fine.
Terminals are such a small, unimportant part of my job I barely even think about them.
Yes, Windows users don't have time for such luxuries when they're constantly fighting a losing fight with an increasingly hostile OS. Playing whack-a-mole dismissing ads, dismissing Edge and reopening links in your preferred browser, waiting for React to render in the start menu, coping with the ever increasing theft of personal data, and on and on and on the list goes. The rest of the time is spent on working around Windows oddities that other developers using sensible OSes simply don't need to deal with. No wonder there's no time to think about anything else.
Show me an environment where I can interact with my system programmatically, where I can compose together arbitrary tools, and which will never, ever, ever break on me, and I'll switch! My experience with graphical environments has been that they rarely compose, often break, and constantly make arbitrary changes that break my workflow. So every time I try something else I end up coming back to the terminal.
But I agree that terminal environments have serious shortcomings. I think it's a real shame we haven't created anything else that does what the terminal does, and I think it's mostly for lack of trying.
You're replying to someone that says POSIX shells are holding people back, not that the terminal is a bad idea, there are many alternative shells which offer benefits over POSIX shells. fish-shell has everything you want from an interactive shell included, xonsh is a mix Python shell, nushell and elvish are adding types and other things to shell.
The VT protocols that all shells have to confirm with are pretty dated and I'd love to throw them off the roof for something less stateful and with multiple font sizes but there's no arguing that text based interfaces are good.
I'm a nushell user but like... job control in nushell is pretty miserable still unfortunately.
Nushell is definitely my fav of the set (xonsh is a neat experiment but ultimately is missing pipeline programming that nushell gives....), and I write personal shell scripts for myself mostly in nu.
Aside: for shell scripts, my preference is something like nu, then python + stdlib, giving me argparser etc, then just zsh/bash/whatever. Seriously annoying how POSIX shells do not give good argument parsing, tho I get it's a hard problem
Now I'm tempted to try xonsh. It looks like it support the amount of bash that I know, and everything else I can just do in Python. (TBH, the things that I would need Python for are obscure enough in bash that I wouldn't otherwise write them myself.)
> I think it's a real shame we haven't created anything else that does what the terminal does, and I think it's mostly for lack of trying
I'd rather just take terminals a step forward, which I agree hasn't happened due to a lack of trying. But the people who aren't trying are the people who are instead tricking out zsh with plugins. I'm a nushell fan myself but my point here is not
> try nushell
but rather,
> be willing to try things that aren't backwards compatible with `sh`
If more people relaxed on that sticking point, we could actually benefit from the excellent post-POSIX work that has been done. As it is, people are reluctant to try new shells for some reason.
There are other options if you want POSIX. But nushell just does things differently (and in a much more sane way with pipes).
Why would you want `test -e "$foo"` when you have `$foo | path exists`? Why `test -n "$foo"` when you have an actual == comparison and pattern matching expressions? And you don't have to worry about quoting things just right in any of the situations.
Yes, you need to learn a little bit of a new thing. You can even implement a test function itself if you really want to. But sometimes it's nice to just dump the legacy baggage.
I could spend hours figuring out all those things, bit I'd rather use that time for something more important.
Configuration is straightforward and easy imo: https://starship.rs/config/
Give it a spin, I think you won't regret it.
Only drawback is that it's not POSIX, no issue for me, but maybe for people who have a lot of muscle memory with bash.
Later I found fizsh, which I love and still use as default shell now. It's basically a configuration around zsh adding the colors, completions, and other good stuff inspired by fish to zsh. Can really recommend it for those who are used to zsh or bash but want their CLI to be more readable. Colors especially help with big command line arguments to show where they start and end, and keeping track of complex stuff like loops and conditional logic in your commands.
Fish is nicer to script in by far, and you can keep those isolated with shebang lines and still run Bash scripts (with a proper shebang line). The only thing that’s tricky is `source` and equivalents, but I don’t think I’ve ever needed this in my main shell and not a throw-away sub shell.
I guess that somewhat breaks with fish: either you use bash -c '...' from the start, or you adopt the fish syntax, which means you need to convert again when you switch to a (bash) script.
I also don’t trust myself to not screw up anything more complex than running a command on Bash, without the guard rails of something like shellcheck!
I don't care for mile-long prompts displaying everything under the sun, so zsh is plenty fast.
First, there are some ways to make fish more compatible with bash.
If you want to do some shell scripting in fish, or running other people's shell scripts (or commands) this may aid you since you wouldn't have to port them (or take less time to port them over).
You can achieve this with a plugin system such as 'oh my fish' or 'fisher'. But, as always, it adds complexity (and bloat :P), you'll need it on every fish shell (including remote systems), etc.
It is a bit akin to having nvim with plugins versus being able to use vi. Sometimes, you're going to need to be able to use the latter.
Also, to people who recently adopted fish: fish has been made more and more compatible with bash throughout those years.
FWIW, I use fish with starship these days.
and script.sh just starts with #/bin/bash
I'm simple
The way I actually have things setup, in case it helps. I don't change my default shell. I actually default to pretty much working within tmux. So, I kept my default shell to what the OS brings, then in my tmux config, I have,
This means, that when I start my terminal, it drops me to zsh (macOS default). Then when I run tmux, it opens fish. The nice thing is that I inherit the environment of zsh.I have my .zshrc and my .bashrc sourcing a .shellrc file which contains most of my env stuff. This keeps random utilities that write to .bashrc and zshrc working within fish too.
After installing and adding it to my bashrc, I was wondering was those version numbers and cloud symbols meant. Turns out: Since NodeJS and Python were installed, it found a good idea to print the respective versions. I could not care less about those versions. The other part was that it thought that I would like to see my AWS region. Well, I mean, I have built something with AWS a few years back, and the config file for that still exists, but no, I don't want to see that region every time I open a shell. Finally, the default is to have the prompt in a new line. I think when you have a long prompt that makes sense, and it might also be a taste thing. However, the documentation has this example at the beginning about newlines:
So I thought `add_newline = false` should do the trick, but it didn't.Luckily, the AI (GPT-5.2) was pretty good at explaining and giving instructions for changing things. So after 30 minutes, everything was understood and configured to my liking. I like the result, but the default was pretty weird.
https://starship.rs/presets/gruvbox-rainbow
You can see that when the segments are empty, they still appear as a 1-width segment, rather than entirely disappearing.
It also makes you configure many things by hand. powerlevel10k has an interactive wizard that lets you design your prompt one option at a time (do you want a nerd font? do you want it one line or two? etc) but Starship makes you manually write escape codes if your preferences don't match one of the presets.
No judgment, but I do wonder what people like about Starship that makes up for these things.
https://starship.rs/presets/#pastel-powerline
I tried making my own and the config TOML syntax isn't expressive enough to support hiding empty segments.
You're right that it's the thing with the Unicode character as separator, which all the alternatives handle just fine: powerlevel10k, tide, oh-my-posh... it's just everyone seems to love Starship, and that's what confuses me.
I don't know if starship is still using Zle. If so, this should be possible to configure without OMZ.
Nice history, command auto complete, and similar beyond just the looks, out of the box
I'm joking but on a more serious note, installing a shell as a default shell seems more complicated than copying over your .bashrc
Maybe I'm underinformed, but I don't personally know any Linux users who convert to zsh, instead opting for fish or something else (oilsh? nushell?).
That already defeats the purpose:
I don't want to copy things around
I never spend time crafting a custom config
So I removed it, then continued using Zsh and whenever I missed something from before I looked up what it was and installed the plugin easily with Homebrew. The whole process took under an hour. I realised I only needed two or three plugins.
Now my shell is fast, without unnecessary bloat, and does what I need. I’m much more productive and happier, and at the end of the day I don’t really see what’s more important than that (within the scope of the conversation).
There's so many better non-shite alternatives. Just one: Zim aka zimfw is one. It's just so sad that there's such a negative creep energy towards "I tried nothing and did nothing and this is where I am". Bad hacker bad. You deserve no voice.
This post is explaining how to set up those things. Less than five minutes to read.
And from the article
> Because cloud services are available globally, I've disabled them.
That's some bad defaults right there.
> When you run a command, it also shows how long it took to execute.
No I absolutely don't want this thing done by the author. Now I am fully in the "customize my config" territory.
Also, most of us are unlike the author, and 0.07s vs 0.38s startup time means no difference.
I think the point of the previous comment has been more than clear enough.
That's quite likely a workflow thing. If you are popping up new (transient) terminals frequently, then a ~400ms wait time for each adds up and makes the entire machine feel really slow. I'm willing to wait extra half a second for a new terminal -- once -- after I've changed my autocompletion configs (rebuild + rehash takes a while), but if I had to wait for that long every time I hit Win+enter and wait for the terminal to become active, I'd be irritated pretty damn quickly too.
You get conditioned to immediate responses pretty fast.
OMZ is still easier to set up consistently. That’s why we use it.
If the concern is the bloat of OMZ then make FMZ - fast my zsh - that is just as quick to set up and doesn’t add “bloat”?
It’s a single command to install oh-my-zsh. I can fire it off, check Slack, and come back in 5 minutes. If I have to take 5 minutes to setup it up, I’m just not going to do it.
In your defense I must say I installed starship ages ago but still not migrated to it from powerline-go because I'm lazy.
Hacker News: Where the hackers don't want to think about any of this command-line nonsense because there is important webshit to build.
Some chefs like to spend hours sharpening their knifes with wet stones. Others are just going to run it through a power sharpener and get on their way.
I like to focus my craft in places other than the terminal.
hackernews: where a large portion of programmers are considered inferior because of the domain they work in (the domain where hackernews also lives)
I’ve also worked with some awesome web devs, to be fair.
I could spend that time tinkering with the internals of an ad-hoc informal system cobbled together in the 1970s and held together by spit and glue.
Or I could just not do that.
Also, the implication that fiddling with shell scripts is somehow a better engineering/programming practice than web programming is laughable at best.
OMZ has been working steadily for me for the past 8+ years. Autocomplete, syntax highlighting, and a concise prompt--really all I need.
https://fishshell.com/
oh my zsh can recreate much of the fish functionality while maintaining good bash interoperability.
If I'm feeling really fancy I may enable vim bindings and add the fuzzy find plugin, but plain fish is so good on its own.
I am also an avid Vim user but I disagree. The default readline is perfectly fine for single line commands (you do have to know your way around some basic commands though C-a/u/k/l/w...). To edit long commands in $EDITOR you can always do C-x C-e in bash/zsh (M-v in Fish). As a matter of fact everytime I pair program with my colleague I always think he is editing those short commands slower than I would have because he has to change modes all the time.
Thanks I didn't know!
Readline settings depend on what you're already used to. If you're comfortable with vi key bindings, then being in normal mode, navigating with `w`/`b`, deleting a word with `dw`, deleting up to a quote with `dt"`, etc., are all done with muscle memory, and should be much faster than learning the equivalent Emacs bindings, pressing unintuitive key chords, or opening the command in an editor. I don't like opening an editor since it's an interruption, and it hides the output of the previous command.
I wish I could have the full power of Vim in my shells. For example, I miss the delete between characters binding. `di"` or `di'` are great for modifying argument values.
$ hyperfine -N "zsh -lc 'exit 0'" "zsh -c 'exit 0'"
Benchmark 1: zsh -lc 'exit 0'
Benchmark 2: zsh -c 'exit 0' It's crazy how their startup time is 380 ms, and I suspect something else might be the reason, not just oh-my-zshIt achieves instant startup by rendering the prompt before the full shell initializes. Since adopting it, I am done fiddling with my shell config and the fact that `zsh4humans` is in maintenance-mode is actually an advantage as it keeps me from wasting time refactoring `zshrc`.
That said, the time of `zsh -ic exit` isn't really meaningful metric for measuring the performance of an interactive shell. See https://github.com/romkatv/zsh-bench#how-not-to-benchmark for details.
https://ruky.me/moving-from-zsh-to-fish-nixos-darwin/
Could you give some examples of issues you encountered because of that? I've been using fish for about 8 years now I can't remember an instance where that was a problem in interactive use.
Another example is small utilities. I wrote one to login to MySQL DBs at work. We have to use Teleport, which I dislike, and it has MFA. So I made a small SQLite DB that has cluster names, endpoints, and secret ARNs (no actual secrets, only metadata), and then wrote a shell function that uses fzf to parse the SQLite DB contents, then ssh tunnels through an EC2 with Teleport to the selected MySQL DB, using expect with a call to 1Pass to answer the password request, and then picks the first available port >=6033 to connect the mysql client. It also tracks the MySQL DB : port assignments in the SQLite DB and waits for the client to exit so it can tear down the ssh tunnel. The only input I have to do beyond selecting the DB is answering a push notification on my phone for MFA.
> replacing 10-LOC shell scripts with Python
The startup time would drive me insane. I love Python, but it’s not great for stuff like that, IMO.
That's not a problem since it's available and when #/bin/bash or env bash is there, it just works.
My bash scripts are stored in a folder on my PATH, so it all just works.
Also one of may main use case is documenting things other developers can do to make their life easier. There are handful of things where zsh behaves differently than bash. And while those handful of thins are not even a POSIX or shell things, they often come up.
The reality is, every day I’m fighting with “developers” who don’t know what the difference between AWS, Linux, and bash is. Throwing “fish” into the mix seems like I’m just being obtuse for no reason. I have sept hours trying to explain to some dumbass that git-bash on windows is not the same thing as Linux only for them to call me “oh he really cares about ‘bash’”-guy. While claiming they are “Linux developers” as they use macOS.
Which is to say, if you need to run a Bash script, run it via `bash foo.sh` rather than `./foo.sh`. There's no need to limit yourself to a worse shell just because there exist some scripts out there written in that shell's language.
It's not perfect, the lack of HEREDOCs are annoying sometimes, and no background-able blocks (eg `{x}&`) means you can't async things as easily in scripts.
Zsh has a lot of advanced stuff (at least for a shell) that can deliver pretty complex scripting such as throw/catching, mountains of variable flags and switches which I do miss when I write fish scripts but really -- I've abused them a lot over the years and now days I would be more likely to just use a "builds to a single binary" language.
I will probably swap to nushell when it gets a bit more stable (in my experience it's runtime is stable, but it's feature set / command names are still shaking out. I really like it's general ideas though in terms operating on structured data.
https://zimfw.sh/
Zimfw definitely has it's own ecosystem, plugins which are zimfw capable. But it's remarkably versatile at bringing in zsh code. Most plugin-systems are pretty ego-centric, demand specific implementations, and zimfw stands out not just for it's ridiculously impressive speed & handling, but for it's versatility too.
Zimfw rocks.
Wowsers!
That +0.5 seconds delay will kill cats everywhere. We must microoptimise the startup time of shells!!!
Or ... we could simply use bash and KDE konsole with, say, 10 tabs. That setup works for me since ages; admittedly I use bash just as a wrapper for simple actions as well as calling a gazillion of aliases and mostly ruby scripts that do the real job. But damn I never knew there were guys who were concerned with +0.5 seconds delays caused by oh-my-zsh. The bloat! Oh my godsers!
Starting one command, realizing you need info from a previous command, often the fastest way to get that info is to open another terminal and start typing and the copy-pasting the relevant piece of cmd. Or needing the output from another command that's scrolled up in a window. In general you end up with a mosaic of tiles each of which is holding key information. So you inevitably open a new tab to make use of the information in the other 3 or 4 windows.
Shell startup is mainly not about waiting for a few terminals in abstraction, but about the way each shell is just a small piece of a longer live workflow and waiting a second for a shell so that you can fill in a piece of a command feels terrible. I think nushell will help cut down on this unpiped inefficiency, but it's usually much simpler to manually glue bash commands together than to parse text output and pipe.
Yesterday just shy over 50, according to entries from `login` in the system log.
I do launch multiple interpreters just to get a fancy coloful cowsay on each launch. Which involves the fortune program, lolcat (via ruby) and cowsay itself (via Perl). I probably should optimise that into a single C binary for better startup times! :)
I don't use oh my zsh, but on one laptop zsh took 600ms to start. I narrowed it down to a strange "bug": adding even a single empty file to the custom fpath caused the slowdown. It bugged me so bad that I decided to try fish again, but this time for real. And this time it stuck with me. I like its architecture (defining functions to change its look-and-feel - great idea!) and of course its 32 ms startup time.
A reason is that I use i3 workspaces, with each workspace being for different tasks, so I don't want to reuse a terminal that has another context.
One issue with keeping a single shell is that the history is full of irrelevant stuff. If you run commands that take a while and print a lot of output, you want it to be as clean as possible. If I want the beginning of the command, I can scroll to the top, and I don't end up with some unrelated output.
I also take quite notes in vim everywhere, often next to long-running commands, using tmux.
I have 90 lines zsh config with 3 plugins (compinit, vcs-info, edit-command-line) and startup-exit sequence takes 0.32s.
You learn very quickly where the lags come though when you work on a big old repository (I learned this on Emacs source code) where getting current branch for jujutsu takes ~5 second. Git is faster in this regard but it still is ~0.3s
I'm not fan of starship (I don't use fancy command line variables in general) but many of those issues can be dealt with awesome bkt caching utility [0]. Instead of live reading just let bkt cache it with long TTL with eager async refreshes. My guess is that Starship does exactly that.
[0]: https://github.com/dimo414/bkt
There's quite a few things the OP's post didn't mention about shell history that I think are really important:
It's possible to roll your own prompt that does helpful things without using starship.Also you can roll your own zsh plugin manager in a few lines of shell scripts, `fast-syntax-highlighting` is a really useful plugin to get real-time feedback when typing commands.
Most of those things are mentioned here https://nickjanetakis.com/blog/i-recently-switched-to-zsh-an..., the post is 5 years old but just about all of that is what I do today still. Since then it has evolved to become better IMO, including using a dedicated Vim zsh plugin which is much improved over the default zsh key binds. Also another plugin to show zsh's tab complete in fzf instead of zsh's window. The tab complete demo video is here https://nickjanetakis.com/blog/hooking-up-fzf-with-zsh-tab-c....
Simple, sensible defaults.
Ships with the Arch Linux installation ISO.
I describe my setup and how to use it on a fresh MacBook here: https://github.com/agrounds/dotfiles
In the end, I realised nothing was as good (to me) as my original Bash set up. I have all the features I need, it's universally supported, and it's fast.
Tip: Install the post GNU2 version from brew
I stripped out most of the OhMyZsh functions (which is pretty modular given a shell package) and created a smaller, leaner package (leanZSH) having only the known stuff I may use. I have been using it without much complaints.
https://github.com/gradientwolf/leanzsh
This feels like a strange hang up to me.
How do you get to hundreds?
I never have more than a one or two dozen terminals at a time, but I definitely open hundred of short-lived ones.
They all do... if you want the niceties of not having to write your own shell config, what would you expect?
It's funny how many people pick up OMZ or doom emacs because some YouTuber told them to do it, then drop them in 6 months because they're all bloaty.
EDIT: The OP fails to mention zsh profiling: zprof. I discovered that atuin is my biggest waster at the moment with like 20ms and rest of the stuff I could clean up.
(Bonus, I use Zoxide to replace the alt+d cd shortcut as it's much faster, and use https://github.com/Aloxaf/fzf-tab for tab completions in the terminal to become fuzzy, very very useful)
On my machine this is handled in zsh, not fzf (but then fzf still benefits). You can configure your shells to sync without exiting. You may need to run one command (or just hit enter with nothing typed, maybe) for the shell history to catch up, but then it should all be there. Relevant options:
# share history among terminals
setopt share_history
# append to the history instead of overwriting
setopt append_history
# append to history incrementally instead of when the shell exits
setopt inc_append_history
I think finding out about this is why I originally switched from bash to zsh several years ago.
Anyway, yeah, all of this adds startup and command invocation time, but the value far outweighs the latency.
Now, I'm deep down the rabbit hole of standardizing all my shells/terminals/configs with Nix. Either a really good or really bad project to start on a Friday night.
Bigger fish to fry if we're being practical.
`mise use node@latest`
Most tools are now directly fetched from github releases without the need for random shell scripts (which is what asdf plugins are).
It also grew to be a task runner and environment manager. At first you might think this is scope creep but they're both opt in and very elegant additions. I don't want to ramble but let's just say they've solved real problems I've had.
I'm a fan of it, and I can't think of a reason why I would use asdf over mise. Its real competition is nix (+devbox/devenv/flox), devcontainers, and pixi.
GPT-5.2 changed the nvm initialization script to:
What I recommend is replacing it with $PATH=(a command to find the nvm default alias directory, detect the verion and load it from that specific version directory directly) so you always have default node in path and then lazy loading only nvm itself, so you can switch when you need to.
Sorry I don’t have the command handy as I’m on mobile but if you paste the above into Opus you’ll get it.
Maybe one day though.
YMMV but I have found using zsh too frictitious to be helpful. Sure, theoretically zsh living in a bash world (lets face it, all scripts are bash) is completely fine but reality seems to differ. Copied a one liner from shell history into your script? Crash. Use arrays? Weird bugs. Use shell builtins? Whoa unexpected interactivity!!! Etc...
Bash is absolutely fine as a default shell. As an added benefit, you don't feel like an invalid once logged in to a container or server.
Other than that, oh-my-zsh with git, systemd, and fzf plugins. Saves a lot of typing.
The main selling point for me is how easy it is to setup.
git commit -> gc
git status --short -b -> gsb
git checkout -> gco
systemctl --user restart -> scu-restart
Nothing that you couldn't come up with yourself, but I've been using for so long it has become a standard for me.
The fzf plugin enables a fuzzy finder when you hit ctrl+r or ctrl+t. You need fzf installed.
Slight pain on a mac to get the latest version and use it as terminal shell, but it gets easier everytime I work on a fresh mac.
[1]: https://eli.thegreenplace.net/2013/06/11/keeping-persistent-...
For nixos users: https://discourse.nixos.org/t/using-zsh-with-grml-config-and...
Super easy to setup, and works very well
It's written in Rust, if you care about that sort of thing (I switched before that was a thing). And for simple one-liners, compatibility actually has improved at least a bit (like you can do && now, which wasn't a thing before).
Write your shell-specific helper scripts or personal scripts in fish, write your portable scripts in Python or Bash. Look, I love standards. Sometimes non-standard things make sense though. Sometimes they even make more sense in the right context.
Or maybe you'll hate it. That's fine. People won't know until they try though.
For something newer and even more different, check out nushell. I don't have much experience with it, but a lot of its ideas are enticing.
I was a bash => zsh/omz person and had these same complaints. But that was 10 years ago. https://github.com/paulirish/dotfiles/blame/main/fish/config...
The baseline fish experience is just better.
Nowadays I just use fish with the out of box installation and it fits all my needs.
I can write fish, scripting or interactively on my shell without thinking too hard about the syntax, but when scripting in bash I require an example or using my snippets to be sure I'm not shooting myself on the foot or writing something that bash will reject right away.
But yeah the syntax with [[, if fi, while stmt; do; done, "$@", case esac, "${!VAR}" and others makes me long for the day fish shell gets "euo pipefail" mode so I can stop writing bash or || true :)
So we still have this inflection point where scripts eventually have to graduate into a "real" language, and while those languages give us proper data types and structures on one hand, they take away conveniences like pipes with the other. It's 2026, and we managed to crack artificial freakin' intelligence before we got a decently evolved shell into the mainstream. </yells-at-cloud>
It auto installs everything if you don't have it. Starts effectively instantly.
External dependencies (or remove their line at the bottom)
- [Mise](https://mise.jdx.dev/) fast asdf, runner, and direnv replacement
- [oxide](https://github.com/ajeetdsouza/zoxide) smart and fast cd replacement
-[atuin](https://atuin.sh/) ctrl + r and shell history finder
- [fzf](https://github.com/junegunn/fzf) fuzzy finder
``` # Plugin Manager
declare -A ZINIT ZINIT[NO_ALIASES]=1 ZINIT_HOME="${XDG_DATA_HOME:-${HOME}/.local/share}/zinit/zinit.git" [ ! -d $ZINIT_HOME ] && mkdir -p "$(dirname $ZINIT_HOME)" [ ! -d $ZINIT_HOME/.git ] && git clone https://github.com/zdharma-continuum/zinit.git "$ZINIT_HOME" source "${ZINIT_HOME}/zinit.zsh"
autoload -Uz compinit; compinit
# Plugins zinit light Aloxaf/fzf-tab zstyle ':fzf-tab:' use-fzf-default-opts yes zinit light zdharma-continuum/fast-syntax-highlighting zinit light zsh-users/zsh-autosuggestions
# Starship zinit ice as"command" from"gh-r" \ atclone"./starship init zsh > init.zsh; ./starship completions zsh > _starship" \ atpull"%atclone" src"init.zsh" zinit light starship/starship
zstyle ':fzf-tab:complete:' fzf-bindings 'shift-tab:toggle' zstyle ':fzf-tab:' switch-group ',' '.' zstyle ':fzf-tab:' continuous-trigger '`'
source <(fzf --zsh)
eval "$(mise activate zsh)" eval "$(zoxide init zsh)" eval "$(atuin init zsh --disable-up-arrow)" ```
cargo install starship --locked
downloads 336 packages. So much for "minimal". cargo is the new npm
We wouldn't celebrate a C project for specifically holding down to say, 10 source files max. We'd celebrate it separating concerns well instead.
Some quick troubleshooting many years ago narrowed the vast majority of the problem down to the git plugin, especially for large, old repos.
I disabled the git plugin and everything has been fine ever since.
Figured I'd dig deeper and bring back the current branch name without the bloat at some point, but it hasn't bothered me enough to do it.
I have used this for a long time, never understood how people would put all of git in between them and the next prompt.
~150ms with minimal setup is good enough for me, although I would prefer <50ms.
https://github.com/romkatv/zsh4humans
For some reason it was slow to load which I found annoying, so I used Claude Code to optimize it. In the end I ended up removing Oh My ZSH entirely, now I have a single .zshrc file that contains everything, and it became much faster.
Similarly I moved from Packer to Lazy.nvim and updated a number of libraries, and from iTerm to Ghostty, Claude Code essentially converted my configs in a matter of minutes
I have a script for each of my projects that I run when I open a new terminal window (Alacritty). The scripts set up tmux with 3-8 terminals, each terminal launches a components, utility or just sits in a folder from which I later run commands.
Having said that, I use only a few zsh plugins, and have a theme configured to not run commands that add extra latency.
I originally switched to ZSH + Oh My Shell because it opens so fast. Ideally plugins would initialize asynchronously but it's not very easy with shell scripts I think.
Check out zsh-bench⁽¹⁾ for a more authoritative approach, including first prompt lag, first command lag, input lag and exit lag.
⁽¹⁾ https://github.com/romkatv/zsh-bench
HN has gone on a decade long crusade against Electron, of course 400ms is a lot.
This investment makes sense for OP who opens hundreds of terminal sessions, but does it make sense to bother about 1s delay when they start the terminal session once in a while? I have several sessions opened all the time, the last time I wasted my 1s on zsh was in 2025 when I rebooted my machine due to a nvidia drivers update.
So far that has been a great move, my terminal tab feel snappy again. One thing I miss (but I’m sure I could find a way to replace it) is `cd ….´
So I figured out what I was using and created my own very paired down version of what I needed. My boot times are much faster and I’ve been totally happy with it. I also learned a lot more about shell configs as a result.
However I agree with other comments that the author's baseline of 380ms is suspicious. I get 150ms (full config, 6 plugins) vs 50ms with no config and plugins.
So I went and had Gemini make me a zsh config with the features I actually use. Took 15 minutes to get all the autocompelte, aliases and search functionality and done.
This can be disabled fairly trivially. I then alias the update command to a homebrew update alias.
https://stackoverflow.com/a/25876379
Shameless plug: I wrote a detailed git prompt in C which is similar to posh-git on Powershell: https://github.com/mahesh-hegde/promptsynth
Even better recently I discovered that FreeBSD has a package for it!
`pkg install ohmyzsh` and 5 seconds later it's ready. Plus I figure it's a bit more secure and insulated to any ohmyzsh breaches.
You'll never get back those milliseconds. Just like I can't get back the time I wasted reading this article.
I'm not saying CachyOS is bad, just that it is in my opinion another layer of complexity that may change/deprecate/etc.
Have your lost your old configs that you worked hard on? That's a shame if so. I love moving my configs I've worked hard on to new machines and instantly getting up and running in a now-familiar environment. It saves so much time and effort.
It's just a handful of files and I manually source them in my zshrc[2]:
It's essentially the same as omz setup I was using before, but loads in just ~25ms (Note: it's on a hard drive, with ddr3 ram and 18ms out of that is spent by compinit)It also fixed another issue I had with Oh-My-Zsh: whenever they (very rarely) tweak their default config - it breaks my muscle memory.
[1] https://codeberg.org/janAkali/dotfiles/src/branch/main/confi...
[2] https://codeberg.org/janAkali/dotfiles/src/branch/main/zshrc
At first, you need them. You'll fall without it. But if you still rely on them after a while, it's not a good sign.
This sounds like overoptimization on a neglible time loss for what is essentially an unique (and dare I say: broken?) workflow.
I use terminals a lot ... but I work with 4-5 day-persistent terminals that I open once a day and keep in the background. The QoL effects of omz outweigh microtuning startup times significantly.
Thinking about that I realized I prefer not to use any plugin manager at all.
But yesterday's conveniences become today's essentials, and those who came in after me have their expectations set by the much more sophisticated things available at the time. Like, I'm still flabbergasted by people—working professionals—who go "I can't program without syntax highlighting, autocomplete, and my IDE generally going bing bing wahoo at me as I work, and I don't know how anybody can." We just type the code in. Like we all had to back in the day.
Anyway I can certainly see where someone younger than about 35, or who came to Linux late, would be completely at sixes and sevens without their colorized racing-stripes shell prompt.
>> My workflows involve opening and closing up to hundreds of terminal or tmux tabs a day.
What?!?
Terminals are such a small, unimportant part of my job I barely even think about them.
Win11 Pro is also fine. I spend radically less time fighting Windows than I spend fighting Linux userspace disfunction.
But I agree that terminal environments have serious shortcomings. I think it's a real shame we haven't created anything else that does what the terminal does, and I think it's mostly for lack of trying.
You're replying to someone that says POSIX shells are holding people back, not that the terminal is a bad idea, there are many alternative shells which offer benefits over POSIX shells. fish-shell has everything you want from an interactive shell included, xonsh is a mix Python shell, nushell and elvish are adding types and other things to shell.
The VT protocols that all shells have to confirm with are pretty dated and I'd love to throw them off the roof for something less stateful and with multiple font sizes but there's no arguing that text based interfaces are good.
Nushell is definitely my fav of the set (xonsh is a neat experiment but ultimately is missing pipeline programming that nushell gives....), and I write personal shell scripts for myself mostly in nu.
Aside: for shell scripts, my preference is something like nu, then python + stdlib, giving me argparser etc, then just zsh/bash/whatever. Seriously annoying how POSIX shells do not give good argument parsing, tho I get it's a hard problem
I'd rather just take terminals a step forward, which I agree hasn't happened due to a lack of trying. But the people who aren't trying are the people who are instead tricking out zsh with plugins. I'm a nushell fan myself but my point here is not
> try nushell
but rather,
> be willing to try things that aren't backwards compatible with `sh`
If more people relaxed on that sticking point, we could actually benefit from the excellent post-POSIX work that has been done. As it is, people are reluctant to try new shells for some reason.
Why would you want `test -e "$foo"` when you have `$foo | path exists`? Why `test -n "$foo"` when you have an actual == comparison and pattern matching expressions? And you don't have to worry about quoting things just right in any of the situations.
Yes, you need to learn a little bit of a new thing. You can even implement a test function itself if you really want to. But sometimes it's nice to just dump the legacy baggage.