As a programmer, my computer use can sometimes look anachronistic, what with my heavy use of Emacs and my use of the terminal to get my work done. I spend an inordinate amount of time looking at monospaced text, and I get a lot of my work done inside my shell of choice, zsh(1), although admittedly, most of my experience with the shell has been in bash(1), and so I’m more familiar with a lot of bash-isms, especially when it comes to the affordances the shell gives you for writing shell scripts — a lot of things are transferable between the two, nevertheless, so I found it quite nice to switch, and there’s a bunch of things that make zsh(1) a slightly more pleasant environment to use interactively.

I really do think that knowing how to use the shell is a Must Have skill for any developer, even if you don’t spend your time in the terminal like I do. It doesn’t mean you have to write shell scripts per se; it can be as simple as figuring out how to get the most out of your shell of choice, knowing how to construct pipelines, or exploiting various features of modern-day shells. Here’s a few of the stuff that make my life on the command line pleasant and productive.

Creature Comforts

My use of the command line can be anachronistic, but that doesn’t mean I have to work like it’s the 1970s through a slow teletype and a 2400 baud modem. No, this is 2018 dammit, and that means using a bunch of features that your terminal emulator and shell gives you, including color, line editing, history, and tab completion— things that you need today to get the most out of your shell experience.

But! The first deal is a choice of typeface and a choice of screen colors. You’re going to stare at that screen for hours; better choose a typeface that’s both readable and looks good. My current dev machine is does not have a Retina screen, so that also means the typeface has to have good contrast and letter shapes at low pixel densities.

For a while, I used one of the preinstalled fixed-width typefaces on macOS (née OS X), Monaco, which was nice, but had some issues at the small sizes I kept using it in. I experimented with turning off antialiasing at the size I used (10pt), which yielded fairly nice sharp text, but I felt wrong turning off antialiasing at all, even though at the pixel density of my screen it did help a lot with readability. It just felt ugly to me, which is definitely not an objective assessment to be fair: I just wanted it to look good as well.

I tried out various other typefaces, including Adobe’s Source Code Pro and Inconsolata, but I finally settled on Hack, for mostly subjective reasons. I like how Hack’s glyphs look narrower to me than the others, and I also liked how code looks in it. Inconsolata looked too muddy at the size I wanted, while Source Code Pro’s glyphs looked too wide and squat for my taste. Another issue was that I wanted the same typeface on both Emacs and iTerm2; Emacs had a weird time handling Source Code Pro at the size I used. So, Hack it is.

In terms of colors, I like to use a dark background, instead of blasting my eyes with all that light, especially at night. Admittedly, my choice of colors is terrible in bright sunlight: I sometimes have difficulty reading my screen under the glare of sunlight, but that’s a situation I’m rarely in, so it’s worth the tradeoff. I have no idea where my current colors come from, to be honest, as I’ve tweaked it over the years. I think it was originally a preset with white text on a dark blue background, which then became a dark grey background, similar to Slate or what not, and which then turned back into a darker blue background. I probably adopted the color scheme from my xterm(1) and Gnome Terminal presets way back. If you want to check it out, you can download it here.

Aside from the eye candy (which, if I’m honest, it is), I also prefer to keep a terminal window invokable via a hotkey, a habit I picked up years ago on Linux when I used ion3 as my window manager of choice. That terminal serves as my go-to place to Get Things Done, if it’s something that isn’t particularly related to a project. I like to keep the terminal output consistent, so that only things related to a project (such as build results, or a log tail) are in a particular terminal. Everything else goes to my hotkey window.

I also tend to use tmux(1) for terminal multiplexing, particularly on servers I manage. I like how iTerm2 integrates pretty well with tmux(1), particularly in how iTerm2 can represent tmux(1) windows as native iTerm2 windows and tabs. Since it can get confusing, I have a separate color scheme for attached tmux(1) windows. Previously, I was a heavy screen(1) user, and I still am very familiar with its keybindings — I will occasionally use it, if tmux(1) isn’t available, or if iTerm2 doesn’t support integrating with the particular version of tmux(1): I haven’t learned some of the keybindings, so I do get somewhat lost if iTerm2 doesn’t integrate with it.

Shell Config

There’s a bunch of ways to get zsh(1) configured the way you want. In particular, there are several zsh(1) configuration/module systems; I’ve chosen to use zplug, which was suggested to me by Zak on Slack when I asked for suggestions. I’ve been pretty happy with it so far, as there isn’t too much magic in the config, and my .zshrc reads in a fairly straightforward way. I’ll probably post my dotfiles one of these days, when I get around to it.

Getting Around

Although I spend a lot of time in the shell, I have to admit that I don’t write a lot of shell scripts; a lot of my shell use has been ephemeral, and most of the time I only need to do something once or twice. For those times I need to execute something repeatedly, an alias usually suffices.

However, I do have a function installed in my .zshrc for prj, which allows me to cd to a project directory, with shell completion: in my home directory, I always have a ~/projects directory, which contains the code of all my projects, organized the way I like it. Under ~/projects, I have one directory per category of projects: work, personal, skunk works, etc.; each project would then be under one of those categories.

It’s pretty straightforward to just cd to a particular project directory with Tab completion, but I’m often somewhere in the disk hierarchy, so I have that particular shell function for going around. The function itself isn’t anything too spectacular— I just use the CDPATH environment variable to nudge cd to jump to a directory under the ~/projects hierarchy. The way CDPATH works with cd is it provides an alternative list of paths that cd will use to find the directory to change to, instead of just the current working directory.

I’ve been using that shell function for quite a while now, and you can take a look at this gist to get an idea of how I use it; that gist is from my bash(1) config way back when: the equivalent zsh(1) function is actually shorter, but similar, and most of the differences are due to the differences in completion support.

Most of the time, as I said, I don’t have shell scripts or functions that I write once and reuse; I instead tend to rely heavily on shell history to get around. C-r (^R, or Control-R) is my friend, and often I have a good memory of commands or pipelines I’ve executed before. If all else fails, I can always do history 0 | grep $foo or history 0 | less to search for something in my command history manually — I have zsh(1) configured to keep history, with the defaults from the history module from prezto.

The other thing I find myself using quite heavily to navigate are shell globs: those things that allow you to specify files whose name matches particular patterns. Most people are familiar with the * and ? globs, but I learned (only a couple years ago, I might add) the use of the {} glob: it allows you to specify a set of substitutions. For instance, I sometimes have a need to make a temporary backup copy of a particular file:

  $ cp{,.bak}

which copies to The glob {foo,bar} expands to foo bar; so foo{,.bak} expands to foo foo.bak.

I find it useful especially when I’m on connected via ssh using my phone, as it’s often hard to use Tab completion in such a cramped space, and in those situations I find it easier to just type in what I intend to do anyway.

Pipelines Etcetera

There are a few commands I use pretty heavily in my day-to-day shell use. One of the go-to commands I use especially for pipelines is xargs(1), as it allows me to stitch together the arguments to another command from the output of a different shell command. For instance, one of my most recent use of xargs(1) is to count the lines of all of the checked-in code inside the git repository of my current project:

  $ git ls-files | xargs wc -l

My current project uses git submodules, so I often find myself needing to look for all references of a string, particularly within Java source files:

  $ git ls-files --recurse-submodules -- '*.java' |
    xargs wc -l

I also find myself using pipelines in general for a bunch of stuff, and not just with xargs. Pipelines are the thing to learn when in the shell, if you ask me, as it allows you to stitch things together.

Another command I exercise a lot is less(1): it’s been my default pager since the first time I used a Linux machine. I often use it instead of tail -f to tail through a log file: hitting F (Shift-F) in less(1) tells it to follow the file, similar to tail(1)s -f switch. Using less in this mode has the added advantage of you being able to interrupt following the end of the file you’re looking at to search backwards for something that’s just scrolled by, or to simply scroll backwards: you’re already in the pager, so it’s pretty convenient.

Finally, grep(1) is always my go-to for grovelling through files to find that one string somewhere; YMMV though, as you might want to check out the alternatives to grep(1), such as The Silver Searcher or Ack— I use grep(1) purely out of inertia, but that doesn’t mean you should too. I also occasionally use sed(1) to do some global string replacements, so grep(1) feels more natural for me to use.

Anyway, I hope you find some of the things I do on the shell quite useful. I don’t claim to be an expert though, and there’s a crapton of things I think I can still learn to do. If you have any suggestions, send me an email or tweet: I’d love to hear some of the things you do to make your shell work for you.

Previously: Workman's Tools