bash is trying to catch up in many areas but not quite there.
Having said that, I've now switched to fish which I don't like but it doesn't need configuring.
That's a plus, but I really don't like how unlike the standard shells fish is. That's not entirely a bad thing (c.f. eshell, which is an interesting experiment), but also not a good thing (c.f. eshell, which is AFAICT unusable).
Another issue I have with fish is its popularity. eshell isn't popular, and so eshellisms don't tend to creep into shared environments; fish is popular, and more and more fishisms are creeping into the world at large. This is not, I think, a good thing at all.
If you're putting shell examples out into the world, they should be POSIX-compatible, or at the very least an extension of POSIX; they shouldn't be some wonky other language (else why use shell at all; use a better language altogether, which fish isn't).
I'd really like to see a good reason to use fish over zsh or bash.
So I feel it's justified to say that fish is a different language than POSIX shell.
set foo "Hello World"
count $foo # gives 1If you want to be constrained by POSIX (as we will all be for the next 100 years or so), there are literally myriads of shells you can use.
However I don't like their new shell syntax, especially env vars handling. Doubt it's configurable.
So while you can't do "PATH=$PATH", you could easily make a function that parses that for you, and have "env PATH=$PATH". It's a limitation.
However, it does mean that instead of something like Bash's insanity around P1 when you want a contextual prompt, fish_prompt is a function, with all the beauty of ifs, fors, and whiles spread out in an easy to read language.
Fish can be hit or miss, but it feels like Lua for the shell, to me.