So I’ve been using Linux now for a while, and am looking to migrate my dev environment to vim and spend more time in the command line. I’m fairly comfortable with bash but by no means an expert. I’ve used zsh with some minor customization but just recently learned about fish. I’d love to hear people’s opinions.
I use fish because I have better things to do than tweak my shell configuration and debug shell plugins.
When I tried oh-my-zsh and prezto (I think?) they came with tons of plugins that performed badly and made it hard to get things done (specifically, they ran git status synchronously on every new prompt, which does not work well in a moderately large repo). Fish had similar features but wasn’t horribly slow, so I use it.
Same. I’ve written a fish plugin, but other than that I just fish pretty much stock. It works and just gets out of my way.
I’m also using fish shell, it find it very user friendly and extremely practical. It gathers all the programs options which you can see when pressing Tab and together with the fzf plugin for history and file search it becomes a very smart shell to use.
I like zsh with oh-my-zsh and Powerlevel10k. This gives me a clear indication of which system I am on and remains POSIX-compliant.
The biggest deal breaker for me for shells like fish are the they are not POSIX-compliant and I need to use remote systems regularly. Doesn’t make sense to use something with a different syntax to me.
Genuinly asking, what is wront/lacking in bash?
I use Fish shell and while it is pretty nice on its own, the fact that it is non-standard does cause problems. Many times you will search for something online and you’ll find nice bash results, which either you will have to execute directly in bash or modify to work correctly in Fish.
I don’t think all of Fish’s design choices are the best, either. But for an OOTB experience, it is nicer than either Bash or Zsh.
In those cases, I simply switch to bash, do the deed, switch back.
An old sysadm introduced me to zsh 28 years ago now and I’ve used it as my primary shell ever since. It’s tried, tested and most certainly works well.
Let the religious shell wars begin … again
Only right answer is of course TCSH. Not much documentation and support, ancient but still receives new bugs in 2021 (on Debian), but attackers hate it! (I love it)
My real suggestion is to learn zsh and fish (and bash). Try using them for all your purposes and in the end you will automatically find the one (or more of them) that suits you best and that you like most for your daily tasks.
If you want you can install starship, which provides a lot of the nifty prompt customization I see in other people’s zsh configs. I’ve been using it with bash for a few months now and like it a lot.
bash with ble.sh! I’m a former fish user, and ble.sh replicates all of fish’s quality of life improvements (that I used, at least) and then some, all with a single
sourcecommand in my .bashrc. And it’s still bash at the end of the day, so online resources to tweak and modify it all still work.I use Linux for work and I’m pretty much fully in bash. What’s the benefit of changing to a different shell? Will all my scripts still work?
Zsh is just bash with plugins and stuff, so regular bash scripts work. fish, as I understand, uses its own language.
Bash code is not safe to run as if it were Zsh, and Zsh has language features Bash doesn’t. They are different languages.
That’s right. zsh is POSIX compliant while fish is not. That’s the reason I switched to zsh from fish.
If you have
on top of your scripts, they will use bash.
ZSH, ZSH, ZSH! Fish is not POSIX compliant, meaning most shell scripts won’t work and it has its own special snowflake syntax.
Also, don’t use Oh-My-ZSH! Just use the package manager in your system.
you can always run scripts with the shell they were written for (and you can even argue that people writing scripts should always set the shebang)
If I have to switch shells all the time when another shell, zsh has the same functionality as fish, without the switching around, I’ll use that. Not to mention fish causes
flatpakto not add Flatpaks to the app menu until restart. Environment variable messes. If I have to install a bunch of other stuff to make fish work, vs make zsh work more nicely, I’ll pick the 2nd one.
Fish, it just works. Customization is super simple and has a really nice webui if you’re into that sort of stuff. Plugins are easy to install with fisher. Out of the box it’s very ergonomic and you don’t have to deal with tons of scripts that may need debugging. Custom shell functions take 2 seconds to set up. Scripts use a shebang to specify the shell they run in, so you shouldn’t have any issues with that. Whenever I absolutely need to run a command with bash, I just switch to it, do what I need to do, and hop back to fish. Highly recommend, haven’t looked back since I started using it a few years ago :)
I use a mix of fish and nu depending on what I’m doing. NuShell is great but still pretty buggy, so I use fish as my default and switch to it when I want to use its features.
I still write most of my stuff in bash however since servers I work with typically only have bash, and so are potential coworkers.
But locally I see no point restricting myself to a POSIX compatible shell, especially for interactive shells. The easier and faster it is to use and customize the better. Being able to parse and use JSON and CSV and other things easily and natively right in the shell is a major quality of life improvement!
Why not use Perl or python for scripting tasks? Bash script is terrible imo.
I mean, I guess technically Perl could do but it wont earn you any favors from your coworkers.
I do use Python for higher level stuff but I don’t see a point to go Python when you’re just gonna call 20 subprocess anyway to do like apt update apt dist-upgrade apt install wget this untar this rsync this. Especially when you can’t even assume you’re going to have Python to provision the box.
That’s why I included Perl, it is always there. Just don’t code as if you were in the nineties and Perl is a perfectly legitimate language, even more so for shell tasks. Bad and good doesn’t depend so much on the language but the coder.
