Why Work In The Terminal

Every craftsman starts his or her journey with a basic set of good-quality tools. A woodworker might need rules, gauges, a couple of saws, some good planes, fine chisels, drills and braces, mallets, and clamps. These tools will be lovingly chosen, will be built to last, will perform specific jobs with little overlap with other tools, and, perhaps most importantly, will feel right in the budding woodworker’s hands.

The Pragmatic Programmer — Andrew Hunt, David Thomas

If you spend enough time reading technical books you will eventually run into anecdotes about how fast some experienced developers were at editing code and how much more efficient computers were before GUI environments became ubiquitous. It often comes off sounding like a grandparent wagging their finger at you while exclaiming how much better their lives were, trudging through the snow back and forth to work while simultaneously raising a family of five children and volunteering at the fire department.

It doesn’t seem possible that an older way of doing something could be better. I mean, we have been working for years to build better hardware, better operating systems, better tools. Doesn’t all that work and effort add up to productivity gains, smoother workflows, faster development?

I have been guilty of thinking this way myself. For a long time I felt I knew better than the previous generation. They don’t know what they are talking about, I thought, they are just too set in their ways to try anything new. Over the last couple years I have realized that I was the one too set in my ways. There are real productivity gains to be had from working in a completely Terminal based development environment.

This transformation happened a little bit at a time. First I started using tmux as a way to quickly start all of the background servers I needed while working on a large project with multiple Rails applications. Being able to simply run a script in the morning to have a fully functional development environment running saved me a lot of time and effort.

I was still not fully converted to a Terminal based development environment though. I did all of my editing work in Atom, database work in Sequel Pro, and Git work in Tower. The Terminal was just running all the servers I needed in the background. The only time I did any serious work in the Terminal was when I had to SSH into staging or production servers to tweak some configuration setting or kick off a data migration script.

The next step on my way to enlightenment was finally learning Vim. I’d tried to pick up Vim a number of times over the years and always wound up running back to whichever editor I happened to be using previously. It wasn’t that I couldn’t see the benefits of using Vim. It becomes clear, relatively quickly, that there are real benefits for editing code built into Vim. The problem was trying to learn Vim and be productive at work at the same time. I was never willing to stick with it long enough to get past the initial productivity loss.

Then, a little over a year ago, I had a bit of down time. I could work on anything I wanted and there was no time crunch to get features out. I decided to give Vim another try. I had been hearing a bit about Neovim and its attempts to introduce background processing into the Vim codebase and the general clean-up of the code. I decided that I would focus on Neovim for this foray into learning Vim. There are some projects available that layer a GUI over Neovim like MacVim or gVim do for macOS and Linux, but Neovim is still very new and none of the GUIs available for Neovim felt polished yet. So, I decided to also stick to Neovim in the shell.

It has now been over a year of writing code exclusively in a Terminal and I can’t imagine ever going back to a GUI editor. Using the tools covered in this book I finally feel like I have a solid set of quality tools that can grow and expand to fit my needs.

What are some of the benefits of working exclusively in the Terminal?

Tailored To You

I’ll walk you through setting up the tools and settings for your initial Terminal development environment. This book should give you a strong foundation in Z Shell, tmux and Vim. You will also have enough information to be able to expand and add to these tools as you see fit. Over time, as you make your own modifications and improvements, your environment will become very personalized to your own needs and tastes. It will be your own personal workbench, every tool in its right place and there when you need it.

Productivity Increases

Building this development environment entirely in the Terminal will allow you to move away, almost entirely, from using the mouse. One of the themes throughout this book will be keeping your hands on the home row. Knowing how to touch type and keeping your hands in the best location for touch typing will increase your productivity a lot. It may not seem like much of a performance hit to grab the mouse from time to time, but once you work for a while without it you will see that everything flows much more easily without using the mouse.

Faster And Smaller

These tools are all extremely fast and have small memory footprints. Full IDEs tend to be slow to load and use large amounts of memory. I remember having to dig around inside the IntelliJ IDEA settings in order to increase the JVM startup memory to over 500MB just to get the application to start in under thirty seconds. Source code files are just text, it shouldn’t require that much memory to edit them.


As you create this development environment I will show you how to store all of the configuration settings in a Git repository. This will allow you to simply clone that repository on any other computer to have your own personalized development environment up and running immediately.


Learning Vim will provide benefits for many other command line tools. The shortcuts used in Vim for moving around, searching for text and other operations are reused in many other tools. This makes a Terminal based development environment very coherent. Learn one set of shortcuts and you will be able to use them in many places.

What Will Be Covered

In this book I will show you how to install, configure and use a completely Terminal based development environment. Along the way you will create your own dotfiles repository which will keep your configuration safe and allow you to move it to other computers easily. I will also show you different ways to improve your speed, both with editing code, and other aspects of a coding workflow.

The main tools we will be using are Z Shell, tmux and Vim or Neovim as well as Git for maintaining our configuration files.

This is Chapter 1, the Introduction. It will give you an overview of what will be covered in this book and provide some insight into why you might want to move to a completely Terminal based development environment.

In Chapter 2, Getting Started, I will walk you through getting your machine prepared for the rest of the book. You will install Git and a Terminal for your chosen platform. I will also cover some Terminal preferences that will improve the usability of the Terminal, and have you modify your keyboard layout slightly to significantly improve your ability to quickly enter many of the shortcut commands used in the book.

Chapter 3, Shell Games, will cover getting Z Shell installed, making it your default shell when you start your terminal and installing Oh My Zsh, which will make configuring Z Shell much easier. I will then cover Z Shell features that will allow you to improve your abilities on the command line. After a brief look at shell basics I will cover Completion, which will allow you to build long command lines with ease. Then I will cover editing the command line and finally some Plugins that are available with Oh My Zsh.

In Chapter 4, Shells All The Way Down, you will install tmux, a terminal multiplexer, which is just a fancy way of saying it can manage multiple shell prompts at the same time. I will cover how to start tmux, how to create windows and panes, how to move around between those windows and panes and how to move around between different tmux sessions. I will also show you how to create your own tmux scripts that you can use to set up an environment for any project.

Then in Chapter 5, Bang! Vim!, you will install a version of Vim, either Vim itself or the newer Neovim. At this point I will show you enough Vim so you can start doing all of your configuration file editing with it. You will configure Vim, add some Plugins and set a theme to make Vim look similar to current text editors. Then you will go a little deeper and learn more efficient Vim editing techniques.

In Chapter 6, Get Sh*t Done, you will learn how all of these tools tie together into a coherent and fast environment for editing code in any kind of project. It is organized around the kinds of things you need to do at various points in a development workflow, so if you get stuck at one particular point you should be able to quickly find a solution in this chapter.

Appendix One will cover a simple setup script for installing the tools and configuring them to use your specialized configuration files.

Appendix Two is a summary of the shortcuts used in the different tools used in this book. It is a shortcut quick reference.

What You Should Know

This book is aimed at developers. I expect that you already have some experience with a programming language and perhaps a framework or two. There isn’t much code in the book, just a bit of shell code that will allow you to setup the final development environment on new machines.

You should be familiar with Git already. I describe how to install it if you don’t already have it, but I don’t go over how to use it at all. If you don’t already know Git you can learn the basics for free at the Git web site. The Pro Git book is also offered for free as web pages, or you can download electronic formats.

You should also have access to one of the remote Git services such as Github, Bitbucket or Gitlab. Most of these services have a free plan, so it won’t cost you any money to store your repositories, but you will need to go through some setup steps. They typically require you to setup SSH keys that will encrypt communications between your machine and the remote service. If you don’t already use a Git repository service I would suggest Github. As of January 2019 they offer unlimited free private repositories. They also have very good documentation for their setup steps.

You should also have at least a little experience using the Terminal. You don’t need to be an expert, but you should know how to change your directory, list files, understand how to navigate the directory hierarchy and run commands. All of the instructions for the steps taken in this book are provided in the text, but it will be handy to have an idea of what is being done.

Finally, you should be comfortable editing files. Each chapter covers installing and configuring the tools covered in the book. Later in the book I hope you will convert to Vim, but for the first few chapters you can use any editor you are comfortable with. If you don’t already have a text editor you can use nano, which is a simple terminal based text editor available by default on macOS and Ubuntu. There is a short nano guide in the Getting Started section.

Accessing The Code

All of the code and configuration files discussed in the book can be viewed in the book’s Github repository.

The dotfiles directory holds all of the configuration files created throughout the book, as well as the tmux and installation scripts.

The addfrac directory holds some C source code that is used as an example in the Building Things section.


In this book you will be working in the Terminal extensively as well as editing files with Nano and Vim. When you see text like this:

  $ echo $EDITOR

That is a shell command prompt. You are meant to enter the command into your Terminal and execute it. The $ represents the shell prompt. Most shell prompts include additional information, but that isn’t relevant for the book, so I just show a simple prompt. The text after the shell prompt should be entered exactly as shown.

There are other places in the text where shell commands are discussed, but it isn’t necessary to actually run the command. In those places the command will be shown in a monospace font.

Whenever I need to show changes to a file I will show the path to the file along with the new contents. The discussion around the file change should make it clear where within the file the text should be placed.


I also cover many different keyboard shortcuts for the tools being used. There are different kinds of keyboard shortcuts in use. Most people are familiar with the modifier key + character kind of shortcut. This would be something like <C-s>, which means to hold down the control key and then press the s key at the same time, then release both.

Vim uses this modifier + character kind of shortcut for many commands, but it uses another kind of shortcut far more often. Vim’s operation is based on Modes. When Vim starts it is in what is called Normal Mode. This mode changes the functions of the keys on your keyboard. When you press the d key it doesn’t enter the d character into the file. Instead it starts a Normal Mode command. Some of these commands are single keys, other are two, three or four keys long. You do not hold every key down like you do with the modifier + character kind of shortcut though. You press and release each key in the command one at a time, much like regular typing.

In this book I will highlight these shortcut commands with a blue background. When you are meant to press and hold multiple keys at the same time I will surround them with angle brackets. So, <C-a> is this kind of shortcut. There are times when you will need to use additional characters after a multi-key shortcut. I will show those as <C-a>d. That means hold the control key and the a key down together then release both, then press the d key.

I also show single special keys, such as <Tab>, <Return> and <Esc> with angle brackets. When referring to the Control key alone I will use <Ctrl>, but when used in combination with other keys I will shorten it, as shown above, to just C and the additional key, like <C-a>. For Vim’s commands I will show the series of characters together without angle brackets. For example, the dw command would mean to press and release the d character, then press and release the w character.

Once Vim is introduced I will often show several editing steps in a table format. Each row in the table is a separate editing step. The first row in the table typically shows the initial text and the cursor position. The cursor is shown as an inverse block, like this  . Each successive row in the table shows the keystrokes used and the resulting text changes.

Keystrokes Results
Use the force force Luke!
dw Use the force Luke!