> I guess debian/ Ubuntu folks will choose bash, osx people will continue using zsh and the openbsd users will keep using that vanilla sh because of the vintage feel.
I believe that using zsh means, for the vast majority of users, using just a small subset of functionality that gives a better UX when compared to Bash.
Both me and my colleagues use zsh this way, and the times I've tried to figure out more advanced functionalities, it wasn't as simple as I expected.
I've read a few points of the article, and although they make sense as improvements, they apply mostly to the scripts domain. I don't recommend writing zsh scripts, because they're subtly different from the (unfortunately) standard that is Bash, besides not being supported (at least until a short time ago) by (the necessary) Shellcheck. If one wants a better experience for scripting, they're better off with a non-shell scripting language altogether (ie. Python).
> I believe that using zsh means, for the vast majority of users, using just a small subset of functionality that gives a better UX when compared to Bash.
What about adding only these functionalities you may care about?
When I tried zsh, what I liked was the history search. Like you, everything else "wasn't as simple as I expected". So I fixed my bash to add and expand what I had enjoyed!
- stores everything into a sqlite database so separate bash in separate terminals can access each other history on the go (without waiting for the session to end and the history being committed),
- add extra details to the history like when the command started, stopped, which with return code, in which directory (more on what that enables below),
- for accessing the history, uses fzy for fuzzy finding, (the one thing I mostly enjoyed in zsh, not zsh but fzy!!)
- provides 2 separate history search contexts: either global (ctrl-t) or "this directory only" (ctrl-r), with extra goodies like excluding commands with a non-zero return error code thanks to the extra things saved
I included a few examples of the SQL queries you can run.
I believe that using zsh means, for the vast majority of users, using just a small subset of functionality that gives a better UX when compared to Bash.
Both me and my colleagues use zsh this way, and the times I've tried to figure out more advanced functionalities, it wasn't as simple as I expected.
I've read a few points of the article, and although they make sense as improvements, they apply mostly to the scripts domain. I don't recommend writing zsh scripts, because they're subtly different from the (unfortunately) standard that is Bash, besides not being supported (at least until a short time ago) by (the necessary) Shellcheck. If one wants a better experience for scripting, they're better off with a non-shell scripting language altogether (ie. Python).