if [[ $- == *i* ]]
then
bind '"\e[A": history-search-backward'
bind '"\e[B": history-search-forward'
fiThis. It's an awesome shell, but I couldn't set is as a default because my already done shellscripts and aliases would stop working. And I also can't set it on server, because then a deployment tool logs in, and expects bash.
And if it isn't default, I might not bother, I'd forget to run it manually most of the time.
(The worst offender is replacing && with 'and' - why not at least enable both and preserve compatibility?)
* zsh-syntax-highlighting: https://github.com/zsh-users/zsh-syntax-highlighting
* My zshrc, for what it's worth: https://github.com/burke/dotfiles/blob/master/.zshrc#L173-L1...
really, really cool
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.
* The main things I like about fish are predictive history completion and syntax highlighting, both of which work about the same with a pair of zsh plugins;
* The syntax occupies what is, for me, an awkward middle ground: it's a bit better than POSIX syntax if POSIX shells didn't exist, but not enough better that I care to juggle the two syntaxes;
* I don't like that fish tries to be "helpful" in certain cases such as lying to you about the delimeter actually used by $PATH.
I have a couple of specific gripes about the syntax, which aren't really inherent issues so much as unimplemented features.
I think if I was going to deviate from a POSIX shell, the alternative would have to be more better than fish to be worth it.