Using the Terminal like it’s 2017

Everyone who writes code sees a terminal. It could have been at school or at work. It could have been some basic server administration. It might even be that one guy at the office who insists that vim or emacs is the one true editor everyone else should learn.

In 2017, web development requires a terminal. 20 years ago we might have been using Microsoft FrontPage. 15 years ago, TortoiseSVN. 10 years ago, there was a clear shift towards TextMate and Sublime, accompanied with tools like Filezilla and Transmit. 5 years ago, NPM and Composer appeared.

Now everyone uses git. We all deal with package management and build steps. It’s become impractical to do web development with using a terminal, because the tools we’re using are too powerful to be confined to GUIs.

But, as people reluctantly open terminals, most web developers still treat terminals like it’s 1997. I’m sure macs shipping with old, BSD versions of common utilities doesn’t help, but frankly, I think most people just don’t know any better. I promise things have changed since MS-DOS times.

Assume all behavior of command line apps can be changed. It’s more likely to be right than wrong.

Pieces of the Command Line

For the uninitiated, it’s easiest to think of it in three pieces. The easiest things to experiment with are changes with your terminal, followed by change to your shell, followed by trying new utilities.

1. Terminal: this is the GUI app you run. It might be iTerm2, Gnome Terminal, Git Bash, or even Bash on Ubuntu for Windows. There’s a lot out there, which slightly different feature sets and UIs.
2. Shell: this is the main app a terminal runs. It defines everything from what directory you’re in to what the prompt looks like. Bash and Zsh are the two most common these days, but there’s plenty of others.
3. Utilities: these are a set of command-line applications that are ubiquitous, mostly thanks to POSIX, BSD, and GNU. For example, ls, tar, zip, and grep are all actually separate apps that are just ported and installed most everywhere.

All of these support configuration. All of these can be swapped. Spend a little time learning and you’ll benefit for years.

Terminals

First, make sure you’re using a modern terminal. For OS X, this probably means switching to iTerm2. For linux, it means basically anything besides xterm and rxvt. Windows is still behind, but I’d recommend either the confusingly named Git Bash or the equally confusingly named Bash on Ubuntu for Windows.

• Get a nice font. While you should always use a monospaced font in terminals, there’s a lot of options out there that people tend to prefer over the system defaults. For example: Hack, Source Sans Pro, Fira, Inconsolata (and Inconsolata-g.) Chris Simpkins has a nice repo and gallery of a lot of the free ones.
• Get a nice theme. Terminals support color themes. Most terminals support true color these days too. Solarized and base16 are good places to start.
• Use tabs in terminals. Tab support in browsers was huge because it kept things more organized and manageable; tabs in terminals do the same thing.
• Use the keyboard to paste. Most terminals use ctrl-shift-v on windows and linux (cmd-v on macs) to paste. Use that instead of right-click or middle-click. I want to take away the mouse every time I watch someone use their mouse to paste.
• Increase scrollback. Most terminals default to only 500–1000 lines history displayed that you can ‘scroll back’ and see. You’re never going to regret setting this to 10000 or higher. Some terminals even support infinite scrollback now if you turn it on.

Shells

Most everything defaults to using a shell called bash; even Windows and OS X. These recommendations focus on bash, but there’s equivalents for other shells. I recommend sticking with bash until you know everything in this article before considering switching.

• Use tab completion. Every command can provide it’s own tab completion logic, and many turn it on automatically. Besides obvious things like tab completing file and directory names, you can also tab complete git (and docker) commands, git branches, even SSH hostnames and the Microsoft Azure CLI. Every time you use tab completion you 1) save keystrokes, 2) check whether there’s any typos so far, and 3) know the autocompleted text won’t have typos either. Think of how many times tab completion would have saved you from running a command with a typo.
• Change your prompt. It’s easy to do. For Bash, it’s the PS1 variable; for Zsh, it’s just PROMPT. For bash, bash-git-prompt is a pretty good option if you want to just try something.
• Configure bash. There’s features in bash that are great and just not turned on by default. Use Bash’s shopt builtin to turn on features like cdspell, dirspell, and autocd. The first two will let bash auto-correct simple typos. The third means you can omit typing “cd “ to change directories. I also recommend dotglob, extglob, globstar, and histappend.
• Add timestamps to your bash history. If you set HISTTIMEFORMAT in your .bashrc, then bash will track and display when commands are run in your command history. While you’re doing that, set HISTSIZE and HISTFILESIZE to 10000 to get 10,000 lines of history instead of the typical 500.
• Use control-r to search through your history instead of history | grep. If you want something even better, install and use fzf.
• Use alt-., !!, and !100 to use previous commands instead of retyping or copy-pasting. For example, alt-. copies the last argument of the previous command onto the command prompt as if you had retyped it.

Utilities

• Use color output when available. For example, ls --color or ls -G on OS X. Turn on color output if it isn’t already in git, npm, and gulp too.
• Use vim not vi. Typing in vi usually still runs vim, it just runs it in a very minimal, limited fashion that’s lacking decades of improvements.
• Use modern equivalents of old CLI apps, like htop instead of top. mawk or gawk instead of awk. bzip2 (or tar cvjf) instead of gzip (tar cvzf.) dig instead of nslookup. less +F instead of tail -f. less instead of more.
• Use aliases. Make bash aliases for commands you run the most, and git aliases for git commands.
• Configure SSH. Create a ~/.ssh/config file and set a default username. Use Host sections to configure usernames and ports for other systems you often use. If you want to do even more, turn on persistent SSH connections.

There’s also some ‘newer’ utilities you should know about:

• tree displays a folder/file structure as a hierarchical tree; probably the simplest way in a terminal to visualize this structure. Especially handy when you’re on a server where opening Explorer/Finder/Nautilus isn’t an option.
• tig let’s you browser through git history. Enable color and unicode characters to make it look even better.
• ack-grep, ag, and ripgrep are all newer alternatives to grep that are nearly always faster than stock grep is.

Remember

Remember that programmers have been using these things for 30–40 years. They’ve been improving and using them for nearly everything imaginable for 30–40 years. No matter what problem you run into, someone else found it and figured out a solution before you.

While this stuff is built to last, it’s not stagnant. I’m particularly interested in the development of Upterm and Hyper, which are terminals built on top of Electron (like Atom.) ripgrep came out last year, as did a new version of bash.

Great programmers master their tools; let’s all start mastering terminals.