Out of curiosity, what use case do you have that makes a POSIX shell a big deal?
I’ve never had issues as a somewhat heavy user.
I’ve never had issues as a somewhat heavy user.
One thing that can be particularly annoying is that it seems to be impossible in fish to evaluate a command in a subshell and embed its output into a string without assigning it to a variable first.
ARGV handling is a little weird too. I understand the impulse to get rid of $1, $2, $3, $*, $@, $#, etc., but it ends up just requiring different gymnastics, like writing `set -e argv[1]` instead of `shift.
Running on a POSIX system, there are decades' worth of shell snippets out there which don't work with fish, but do with sh, ksh, bash & zsh.
Fish is just gratuitously incompatible. Having fish-users on a team is a pain, because they'll write everything in fish and either not bother producing sh equivalents, or produce insufficiently-tested sh equivalents. It's just a lot of pain and bother, and what's the benefit? Zsh does everything fish does and more, so why not just use it?
Edit: I just wish that the original fish developers had chosen to implement all their cool features and be sh-compatible, or at the very least had exercised some wisdom in where they chose to break compatibility. Instead, it very much feels like a 22-year-old's project: full of ideas, some good & some bad, and needlessly without respect for the past. I've no problem with rejecting the past when the past is broken (and sh is broken in places); my problem is with the equivalent of saying, 'hey, English spelling is terrible, soh Aiv dəseidid tū dəvelup mai ohn.'
Where stuff like fish is a pain for me is with apps that for whatever reason need shell integration (virtualenv, for example). Non-POSIX shells end up being an afterthought there, so you end up with no or buggy support, and end up having to find some other custom variant (virtualfish, etc.) to get good behavior. Sticking with a more mainstream shell tends to be safer there, and zsh barely makes it over that line.