Scripts will still work as long as they have the standard #!/bin/bash at the top.
Aliases - in .bashrc - unfortunately will need to be replaced by Fish functions; defined in the "~/.config/fish/config.fish" file by default.
The only real thing that keeps tripping me up with Fish is that it doesn't support shortcuts like "!$ ". I keep on typing that in, but due to the nature of Fish, it can't (or won't) recognise it. But the excellent history functionality does make up for this a fair bit.
Having said that, Fish is by far the best shell I've tried. I gave zsh a go for about half a year and got fed up with the autocompletion and general slowness. As a shell, Fish just behaves quickly and fairly naturally, with few exceptions (!$ ...).
I highly recommend it as an improvement over bash.
> I keep on typing that in, but due to the nature of Fish, it can't (or won't) recognise it. But the excellent history functionality does make up for this a fair bit.
I was interested in this comment so I looked into the documentation to find out why this is. Here's a link to the FAQ for anyone else interested:
I'm a little sore that the FAQ Listed that as an alternative. That was how I did it in bash before I realized I could do "sudo !!" which was waaaaay more convenient.
It's a step backwards. Which I'm fine with, as long as you step forward again, in some way.
I made a slight variation (and also posted it there):
function .runsudo --description 'Run current command line as root'
set cursor_pos (echo (commandline -C) + 5 | bc)
commandline -C 0
commandline -i 'sudo '
commandline -C "$cursor_pos"
end
bind \es ".runsudo"
Instead of outright `execute`ing the command, the above would save the cursor position. You can (theoretically) bind `\cs` so control-s adds the sudo (instead of option-s), but I couldn't get it to work.
Yes -- fish is not bash, so anything defined in your .bash_profile etc. will break, though there's usually an easy alternative way to do it in fish. Scripts should be fine though, since they usually explicitly call bash when you run them, so will still run using bash.
I switched to fish about six months ago and have been very happy with it. I spend a lot of my working day in the command line, though not doing anything exotic, and find it very pleasant to use.
It wouldn't read your .bash_profile, because it cannot. Any variables that are set by your .bash_profile will therefore not be set, and anything that depends on them being set may break.
Fish is not a POSIX shell and does not try to be one. In contrast, bash, zsh, and others are supersets of the original sh and backwards-compatible. Fish is not.
For example the exit code of the previous command, instead of POSIX $?, you can get it as $status.
Look out for errors with third-party applications that shell out and expect to find bash or something compatible. I had to explicitly set shell=/bin/bash in .vimrc before any plugin initialization in order to avoid breakage after changing my login shell to fish.
I've found that leaving your login shell as bash but making fish the default executable for any terminal emulators you use will pretty much prevent any breakage.
