About davelab

I frequently observe other engineers struggling to work from the command line. Often, they have no idea how much they are actually struggling because they’ve never seen a more efficient setup, or they think that learning to use the shell is unapproachable because it’s too difficult and strange.

Using the shell is becoming a lost art. It’s still the fastest and most efficient way to work with your operating system. - Me

The first inspiration I had was when I overheard some other people complaining that ZSH doesn’t share command history across multiple terminals. So I showed them the SHARE_HISTORY option, and some other related options, to enable the shared history functionality that they wanted.

So the first idea was just to write a document that outlined my configuration file, line-by-line, while giving just a bit of context and some useful links on each topic. I would share that with junior engineers, or anyone who wanted a guide for configuring their shell.

My configuration file is only about 75 lines long, but explaining what each line does requires a surprising amount of context first. And things that you may want to customize may require learning another mini-language. The document stated getting longer, and I needed to break it up into multiple files, to make each file more approachable than one very long document.

As I started breaking the document into files based on topics, I decided to just use the GitHub repository view as the interface for reading this content. It renders Markdown and shows inline images, you can link between Markdown files in the same repository, and you don’t need to find separate hosting.

The next source of inspiration came when I shared a command for someone to run, a simple find with -exec command, instead of making a one-off Python script. But, since they didn’t understand what the command did, they didn’t want to run it. And even when I convinced them it was safe, they didn’t have coreutils (required for the find command) on their MacBook system anyway.

So now I want to make this a course on command line productivity instead of just a walk-through of my own ZSH configuration. That requires covering everything from configuring your system, piping, scripting, globbing and expansion. But the important, overarching lesson, is the value of streams and “lines of text” that can be processed like batches of tabular data. This, combined with piping, is what makes it possible to transform the output of a command to do things like reporting, configuring, or even generating other complex commands to execute.

A little later, I heard about GitHub Pages. With the push of a button, it would create a free hosted site and publish all of the Markdown files from the project as a Jekyll static site. Just… I didn’t really like the default layout for what I wanted.

So I found out you can create a Jekyll project and build it the way you want, then use GitHub Pages (via GitHub Actions) to publish the compiled static site on every commit. I think I could have used any static site generator, but Jekyll seemed like the least friction (except learning a new HTML templating language and working with Ruby).

Since I was able to customize everything myself, I wanted some specific features:

1. Layout should support mobile and “1/2 screen” view (for working with browser and terminal side-by-side). When the page gets too narrow, the navigation menu should pop-up into a horizontal bar on the header.
2. There is no need for JavaScript here, even where it might be a little convenient in some places. So this site is strictly no-script.
3. I wanted to use a “programming” mono-space font, one that has support for extra glyphs and symbols.
4. I wanted to chase LightHouse scores for a bit as a way to learn more about web performance.