Why I chose Fish over Bash for students

I’m currently the lead instructor at Code Platoon and an instructor/developer at the Turing School of Software and Design.

I’ve been advocating the Fish shell and when the choice is up to me, I choose that for my students. Enough people ask about the decision, particularly in relation to the preinstalled Bash shell, that I figured it’s worth laying out my reasoning.

TL;DR

Fish addresses many of bash’s shortcomings and is much kinder to newcomers, with only 3 or 4 new things to learn for people coming from Bash.

The decision give students my defaults

I used to let students choose whatever shell/editor/etc they wanted. But most students are not in a position to understand the tradeoffs, and they fear making changes. This would often lead to situations where students would defer all choices and 6 months into the program wouldn’t have so much as a coloured prompt. Why does a coloured prompt matter? It means that every command they type, they have to scrutinize carefully to see what the command was and what the output was. Add that to all the other costs of being new, and it gets expensive quickly!

The problem with being a beginner is that you get a lot of practice in staying a beginner. What a beginning tennis player does most of the time is chase the ball. They get to be really good at chasing the ball, but all other forms of tennis involve hitting the ball.

— Tim Gallwey

I eventually decided that letting them choose had little value because it meant inconsistent environments, most in some state of brokeness. Students were mostly overwhelmed by all the decisions they had to make, and were too ill-informed to understand the tradeoffs anyway. It turns out that overchoice leads to dissatisfaction, regret, and paralysis. I know the tradeoffs, and what they struggle with, so I’ll make those choices for them.

So then, the question becomes “what environment should I give them?” I’ve tried 4 different editors now (Sublime, Atom, RubyMine, and Vim), and two different shells (bash, fish). In the end, I realized that most of the decisions I make for myself are better than the defaults, and due to my prioritization of feedback, my choices are generally good for learners. One of those decisions was the Fish shell, and this post is intended to explain why it is a better default than the Bash shell.

The case for Bash

Based on conversations I’ve had, there are 3 arguments for Bash:

1. It is already installed.
2. Most shell code is written for Bash.
3. Most people that can help know Bash.

My perspective: We are installing many new things already, and don’t accept this as an argument that we should stick with many other defaults. Fish is mostly compatible with Bash. And there are only a small number of new things someone with Bash knowledge needs to learn in order to use Fish.

The case for Fish

Highlighting

Fish will highlight the command they are typing differently from the arguments they are giving, making it apparent that this first bit of text is different. If it is not made explicit like this, students can go months before they understand that the first thing they type is a program and the things after it are arguments.

If they type an incorrect command, it highlights this in red, so they immediately know, as opposed to knowing when they get an error message after running the completed command.

It highlights quoted args differently to let you know they are a single argument, and if you have incorrect syntax, it highlights this in red:

Suggestions

Fish will suggest previously typed commands. What was that command to start postgresql? type pg and it will suggest whatever I put last time! This is even directory aware, so that suggestions will be be prioritized based on where I use them!

It understands program options and lets you tab complete to see what the option is and a brief description of the option:

Highly compatible with bash

Syntax for common use cases is usually the same:

Wildcards are the same

Redirects are the same

Pipes are the same

Things Fish does much better than Bash

It correctly handles string escaping where bash completely falls down (Bash later added $'this kind of string' to compensate).

It’s much easier to set up a prompt that changes based on the success of the previous command (bash can do this, too, it just took me several years to figure out the right way to do it — the PROMPT_COMMAND variable, if you’re curious)

When you get to scripting it, the language syntax is dramatically more understandable. I tried to write a function just now, in bash it took me 2 tries, then I wrote it long-hand so I could press up to see how it translates to one line (5 tries in the recording because I messed up). Notice that even if the fish version wasn’t obvious, the autosuggestion from my previous success would let me know. And while defining it, I get syntax highlighting and proper indentation.

Fish handles string escaping and allows you to edit across lines. I’m not sure what library bash uses, but watch what happens when I try to go up to edit what I wrote (also notice I got the name wrong at first, but fish highlighted it in red, so I knew to go fix it). It’s good enough that I’ve written 30 line programs inside of strings in the shell!

Bash only recently got basic data structures like hashes and arrays, and the syntax to use them is both unintuitive, and forgiving of mistakes (meaning it is easy to do the wrong thing, and difficult to realize it). Here’s an example: setting arrays involves complex syntax, whereas in fish, it’s the same syntax you use for everything else (a command followed by args) and look how many ways there are to access it wrong in bash, many of which you wouldn’t realize you got wrong unless you knew to check it against an element with a space. And you have to opt into safe behaviour by quoting everything… I’m not even sure what the unquoted use case is!

And here’s bash’s syntax for hashes: http://stackoverflow.com/questions/1494178/how-to-define-hash-tables-in-bash

Another thing about Bash

Also, the relationship between .bashrc, .bash_profile, and .profile is utterly confusing and leads to bugs when things get placed in the wrong file (I’m pretty sure this is because it’s inconsistent across operating systems). A very competent friend (maintainer of gems we all use, who prides himself in knowing everything) once confidently told me what they all did, and I tried it in front of them and it was incorrect.

Summary

So, Fish addresses many of bash’s shortcomings and is much kinder to newcomers, with only 3 or 4 new things to learn for people coming from bash. I documented most differences I could think of over here, and that document goes much further than even I actually need. In our material on the shell, there’s only one place we need to differentiate it from bash, which is in how environment variables get set (1, 2). So the cost is low and the value is high.

Salutation

Hope that explains my motivations sufficiently