“Live in the command line.”

One of earliest instructions in week one was to “live in the command line.” Avi described that computers should be more than the media consumption devices they are to most users. That everything we need to do on a computer can be done exclusively from the shell. That, as programmers, we need to make the command line our home.

But what is the command line? I’ve used Terminal long enough to be comfortable using it, but what is it? Is Terminal the same as the command line and the shell and bash? What am I really doing when I use these tools? What are the kernel and command line and Bash, and how should I even use all those words?

Rest assured, I can’t and won’t answer all of those questions in their completion. I’m keeping a narrow scope, as Avi instructed, looking to understand a few specifics rather than write a book on computing.

A few definitions

In a couple minutes, these terms and definitions will fit into a more cohesive framework.

Terminal (Terminal.app): the terminal emulator on Mac OSX, a GUI for the command line interface.

Command line interface (CLI): a means of interacting with a computer program where the user issues successive lines of text commands.

Shell (or command-line interpreter): the user interface for access to an operating system’s kernel services, the first of which was Bell Labs’ Multics, followed by Unix, etc.

Bash: the Bourne-again shell, a Unix shell replacing the Bourne shell (sh), default on Linux and Mac OSX.

Kernel: a computer program that manages input/output requests from software and translates them into data processing instructions for the central processing unit and other electronic components of a computer.

The framework

With those definitions in mind, the framework in the image below may be helpful.

Just kidding—look at this one instead.

The left side of image includes the hardware (which includes the CPU, memory, devices, etc.) and the software applications (which includes all the applications we know and love) bridged by the kernel. As was defined earlier, the kernel manages the hardware and enables programs to use it. It is a fundamental part of a modern computer’s operating system. It’s hugely important. And it is where the terminal and command line come in.

Making it clearer

Go back and reread the definitions; you’ll notice an order to the terms. They appear from highest to lowest level, from the graphical user interface of the Terminal application to the kernel, a core piece of the machine’s infrastructure.

When we type a command into the Terminal (at the highest level), that command is interpreted by the shell (aka, the command line interpreter, which is very slightly removed from the command line interface) and then passed to the kernel

That’s all I need to know for now; I’ll leave it to people much smarter than me to explain the kernel. Suffice it to say: that interaction between the Terminal, CLI, and kernel is what enables us, as programmers, to type simple lines of text that are also very powerful commands.

Bringing it home

My main takeaway is this: I now know what I mean when I say I’m using the command line, or Terminal, or the shell, or Bash, etc. We were pointed to this Chinese proverb recently:

“The beginning of wisdom is to call things by their right names”

Perhaps by recognizing these subtle differences I can attain programming wisdom.

One final idea: metaphors. So much of our computer is made up of metaphors: windows, the screen, double-clicks—all metaphors for something else the computer is doing. When Avi introduced us to Alan Kay recently, he introduced the idea that by inventing the GUI Kay introduced a metaphor—a tool that makes the user’s life easier—for a given process. If nothing else, think of the terminal as exactly that: a (high-level and vastly simplified) metaphor for the kernel’s management of the underlying processes running on the machine.