From zsh to fish

Juri Rischel Jensen
3 min readMay 6, 2020

Most DevOps engineers go about their day, without worrying too much about what shell they use. And as the default shell for most Unices is Bash, that is what they use.

During the 24 years I’ve worked with Linux and other Unices, I also stuck with Bash, without even trying some of the other alternatives. But the alternatives 10–15 years ago wasn’t that great either. Bash was, seen with broad perspective, the best shell out there. And it was for me too, until 5–6 years ago, where I felt that bash had it’s limitations.

So I looked for alternatives, and as many others, I found myself intrigued by zsh, which had some simple, but very interesting features.

Now, a shell is a very important part of your toolbox, when most of your work consists of writing and executing code. At that particular time I had written a lot of Puppet automation code, and had started on writing Ansible code. So I did my work in a shell and an editor, for the most part. And the limits of Bash hit me again and again. But Bash was also one of my primary tools, so I couldn’t just throw it away and start using a new tool. I had to test the waters first.

As my primary platform of choice is macOS, I created a profile in iTerm, set the shell to zsh, and tested it out in my daily work. If I felt that zsh hindered my job in any way, I switched back to good ol’ Bash and continued my work. Even though I had to switch back a couple of times during the first days, I found myself working full time with zsh in a matter of days.

But now I had this shell in my hand, that enabled lots of customization, especially with regards to the look of the prompt. And that, of course, made me use a lot of my time customising how the prompt looked. To a very high extent. And of course I had to match that look in my preferred editor, ViM, with more customization time used. I used countless hours on getting the look that I thought I needed, and the extra functionality provided by plugins to zsh.

But suddenly I experienced something that I never had with Bash — problems when upgrading either plugins, zsh, or some of the supporting programs that the plugins used (Python to name one). Problems that gave me hours of work in fixing it. Problems that drove me crazy. I also started using plugin managers, and used 3 different ones during my time with zsh — none of them worked as I wanted them to. And that’s when I started to look around for an alternative shell.

The fish shell popped up during my searches, and intrigued me — both because of the name, but also the simplicity of it’s configuration. It had most of the features I loved from zsh enabled by default, so I didn’t need to install a lot of plugins to get it to a state that I could work with. And the rest I could enable with plugins.

But for some reason I went on using zsh for a couple of years more, until last year when I got a consultancy assignment where I could choose a MacBook as my laptop. To mix things up for a change, I decided to change the default shell to fish, without the possibility of (easily) going back to bash. And during the first week I found the plugins I needed, the theme that I wanted and a very short config. I chose to use a plugin manager once again (OhMyFish) and haven’t felt the need to change that since.

I still experience some problems from time to time, but that usually happens when I try to use Bash syntax where it’s different in Fish. But most of the times it means that I discover that the Fish syntax is much clearer than the Bash equivalent. This doesn’t mean that I’ve rewritten all my shell scripts to use the Fish syntax, but instead that I use the Fish syntax for interactive work, and bash for the scripts that I write. And I find that this is a good place to be.

--

--

Juri Rischel Jensen

This is the space for my thoughts and methods regarding my work, my hobbies and the way I train and eat.