Take Control of the Mac Command Line with Terminal (2015)

Understand Basic Command-Line Concepts

In order to make sense of what you read about the command line, you should know a bit of background material. This chapter explains the ideas and terminology I use throughout the book, providing context for everything I discuss later in the book.

What’s Unix?

Unix is a computer operating system with roots going back to 1969. Back then, Unix referred to one specific operating system running on certain expensive minicomputers (which weren’t “mini” at all; they were enormous!). Over time, quite a few companies, educational institutions, and other groups have developed their own variants of Unix—some were offshoots from the original version and others were built from scratch.

After many branches, splits, mergers, and parallel projects, there are now more than a dozen distinct families of Unix and Unix-like operating systems. Within each family, such as Linux (a Unix-like system), there may be many individual variants, or distributions.

Note: A Unix-like system is one that looks and acts like Unix, but doesn’t adhere completely to a list of standards known as the Single UNIX Specification, or SUS. Mac OS X 10.5 Leopard or later running on an Intel-based Mac is a true Unix operating system. Earlier versions of Mac OS X, and any version running on PowerPC-based Macs, were technically Unix-like.

Mac OS X is a version of Unix that nicely illustrates this process of branching and merging. On the one hand, you had the classic Macintosh OS, which developed on its own path between 1984 and 2002. On the other hand, you had NeXTSTEP, an operating system based on a variety of Unix called BSD (Berkeley Software Distribution). NeXT, the developer of NeXTSTEP, was the company that Steve Jobs founded after leaving Apple in 1985.

When Apple bought NeXT in 1996, it began building a new operating system that extended and enhanced NeXTSTEP while layering on capabilities (and some of the user interface) of the classic Mac OS. The result was Mac OS X: it’s Unix underneath, but with a considerable amount of extra stuff that’s not in other versions of Unix. If you took Mac OS X and stripped off the graphical interface, the Cocoa application programming interfaces (APIs), and all the built-in applications such as Mail and Safari, you’d get the Unix core of Mac OS X. This core has its own name: Darwin. When you work in the command-line environment, you’ll encounter this term from time to time.

Darwin is itself a complete operating system, and though Apple doesn’t sell computers that run only Darwin, it is available as open source so anyone with sufficient technical skill can download, compile, and run Darwin as an operating system on their own computer—for free.

What’s a Command Line?

A command-line interface is a way of giving instructions to a computer and getting results back. You type a command (a word or other sequence of characters) and press Return or Enter. The computer then processes that command and displays the result (often in a list or other chunk of text). In most cases, all your input and output remains on the screen, scrolling up as more appears. But only one line—usually the last line of text in the window, and usually designated by a blinking cursor—is the actual command line, the one where commands appear when you type them.

Note: Although Darwin (which has only a command-line interface) is part of Mac OS X, it isn’t quite correct to say that you’re working in Darwin when you’re using the Mac OS X command line. In fact, the command line gives you a way of interacting with all of Mac OS X, only part of which is Darwin.

What’s a Shell?

A shell is a program that creates a user interface of one kind or another, enabling you to interact with a computer. In Mac OS X, the Finder is a type of shell—a graphical shell—and there are still other varieties with other interfaces. But for the purposes of this book, I use the term “shell” to refer only to programs that create a command-line interface.

Mac OS X includes six different shells, which means that your Mac has not just one command-line interface, but six! These shells share many attributes—in fact, they’re more alike than different. Most commands work the same way in all the shells, and produce similar results. The shells in Mac OS X are all standard Unix shells, and at least one of them is on pretty much any computer running any Unix or Unix-like operating system.

The original Unix shell was called the Bourne shell (after its creator, Stephen Bourne). The actual program that runs the Bourne shell has a much shorter name: sh. The other Unix shells included with Mac OS X are:

· csh: the C shell, named for similarities to the C programming language (Unix folks love names with puns, too, as you’ll see)

· tcsh: the Tenex C shell, which adds features to csh

· ksh: the Korn shell, a variant of sh (with some csh features) developed by David Korn

· bash: the Bourne-again shell (yet another superset of sh)

· zsh: the Z shell, an advanced shell named after Yale professor Zhong Shao that incorporates features from tcsh, ksh, and bash, plus other capabilities

In Mac OS X 10.2 Jaguar and earlier versions, tcsh was the default shell. Starting with 10.3 Panther, bash became the new default. Even if you’re running a later version of Mac OS X, though, your account may still be configured to use tcsh if you migrated from Jaguar or older.

In this book, I discuss only the bash shell. Some may argue that zsh has a superior feature set or tcsh is more universal—and I can’t particularly disagree—but because bash is the current default and can easily handle everything I want to show you about the command line, that’s what we’ll be sticking with here.

A bit later in the book, in Set a Default Shell, I show you how to confirm that you’re using the bash shell and how to change your default, if you like.

What’s Terminal?

So, how do you run a shell in order to use a command-line interface on your Mac? You use an application called a terminal emulator.

As the name suggests, a terminal emulator simulates a terminal—the devices people used to interact with computers back in the days of monolithic mainframes. A terminal consisted of little more than a display (or, even earlier, a printer), a keyboard, and a network connection. Terminals may have looked like computers, but all they did was receive input from users, send it along to the actual computer (which was likely in a different room or even a different building), and display any results that came back.

A modern terminal emulator program provides a terminal-like connection to a shell running either on the same computer or on a different computer over a network.

Quite a few terminal emulators run on Mac OS X, but the one you’re most likely to use is called—you guessed it—Terminal, and it’s included as part of Mac OS X. Although you’re welcome to find and use a different terminal emulator (such as iTerm 2) if that’s your preference, in this book I discuss only Terminal.

Terminal Commands? Not Really!

At the risk of redundancy, I want to emphasize where Terminal fits into the scheme of things. A common misconception is that Terminal is the Mac OS X command-line interface. You’ll hear people talk about entering “Terminal commands” and things of that sort. (Even I have said things like that from time to time.) But that’s incorrect. Terminal is just a program—one of numerous similar programs—that gives you access to Mac OS X’s command-line interface. When you run a command-line program, you’re running it in a shell, which in turn runs in Terminal.

So, to summarize: you use Terminal to run a shell, which provides a command-line interface to Mac OS X—a variety of Unix (of which the non-graphical portion is known as Darwin). You can use the Mac OS X command line successfully without having all those facts entirely clear in your mind, but a rough grasp of the hierarchy makes the process a bit more comprehensible.

What Are Commands, Arguments, and Flags?

The last piece of background information I want to provide has to do with the kinds of things you type into a Terminal window. I provide extensive examples of all these items ahead, but I want to give you an introduction to three important terms: commands, arguments, and flags. If you don’t fully understand this stuff right now, don’t worry: it will become clearer after some examples.

Commands

Commands are straightforward; they’re the verbs of the command line (even though they may look nothing like English verbs). When you enter a command, you tell the computer to do something, such as run a program. Very often, entering a command—a single word or abbreviation—is sufficient to get something done.

Note: As a reminder, when I say “enter this,” I mean “type this, and then press Return or Enter.”

For example—not to get ahead of myself but just to illustrate—if you enter the command date, your Terminal window shows the current date and time.

Note: Many commands are abbreviations or shortened forms of longer terms—for example, the command pwd stands for Print Working Directory.

Arguments

Along with commands (verbs), we have arguments, which you can think of as nouns—or, in grammatical terms, direct objects. For example, I could say to you, “Eat!,” and you could follow that command by consuming any food at hand. However, if I want you to eat something in particular, I might say, “Eat cereal!” Here, cereal is the direct object, or what we’d call an argument in a command-line interface.

On the command line, you must frequently specify the file, directory, or other item to which you want a command applied. In general, you simply type the command, a space, and then the argument. For example, the command nano, by itself, opens a text editor called nano. (In other words, entering nano means “run nano”—you tell the shell to execute a command simply by entering its name.) But enter nano file1 and the command instead opens the file file1 using the nano text editor. Here, file1 is the argument to the command nano.

Note: Always be sure to type a space after the command and before any arguments.

Some commands accept no arguments. Some take optional arguments. And some commands require one or even several arguments. For example, to change the modification date of three files—file1, file2, and file3—I can enter touch file1 file2 file3. But other commands require multiple arguments that have different meanings (as in “Process file1 with the information found in file2 and store the output in file3”). In these cases, the order in which the arguments appear is critical. I detail which commands in this book take arguments, the order of those arguments, and the circumstances when you need to use those arguments.

Flags

Besides verbs and nouns, we have adverbs! In English, I could say, “Eat cereal quickly!” or “Watch TV quietly.” The adverbs quickly and quietly don’t tell you what to do, but rather how to do it. By analogy, an expression in a command-line statement that specifies how a command should be accomplished is called a flag, though you may also hear it referred to as an option or switch. (Some people consider a flag to be a type of argument, but I’m going to ignore that technicality.)

Suppose I want to list the files in a directory. I could enter the ls (list) command, which would do just that. But if I want to list the files in a particular way—say, in a way that included their sizes and modification dates—I could add a flag to the ls command.

The flag that ls uses to indicate a “long” listing (including sizes and dates) is -l. So if I enter ls -l (note the space before the flag), I get the kind of listing I want.

Flagging Enthusiasm

I should mention a couple of irritations with flags:

· First, you’ll notice in this example that the flag was preceded by a hyphen: -l. That’s common, and it enables the command to distinguish a flag (which has a hyphen) from an argument (which doesn’t). Unfortunately, Unix commands aren’t entirely consistent. You’ll sometimes see commands that require flags with no hyphen, commands that require flags with two hyphens, and commands with flags that can appear in either a “short” form (one hyphen, usually followed by a single letter) or a “long” form (two hyphens, usually followed by a complete word).

· Second, a command may take more than one flag. (“Eat quickly and quietly!”) For example, you might want to tell the ls command not only to use the long format (-l) but also to show all files, including any hidden ones (-a). Here you get two choices. You can either combine the flags (ls -la or ls -al) or keep them separate (ls -l -a or ls -a -l). In this example, both ways work just fine, and the flags work in any order. But that isn’t always the case; some commands are picky and require you to list flags one way or the other.

Don’t worry about these differences; just be aware that they may come up from time to time. For now, assume that most flags will start with a single hyphen, and that the safest way to express most flags is to keep them separate.

Some commands require both arguments and flags. In general, the order is command flag(s) argument(s), which is unlike usual English word order—it would be comparable to saying, “Eat quickly cereal!” For example, if you want to use the ls (list) command to show you only the names of files beginning with the letter r (r*), in long (-l) format, you’d put it like this: ls -l r*.

Sin Tax?

As you read about the command line, you’ll sometimes see the word syntax, which is a compact way of saying, “which arguments and flags are required for a given command, which are optional, and what order they should go in.” When I say that the usual order is command flag(s) argument(s), I’m making a general statement about syntax, though there are plenty of exceptions.

One place you see a command’s syntax spelled out is in the man (manual) pages for Unix programs (see Get Help), at the top under the heading “Synopsis.” For example, the man page for the mkdir (make directory) command (see Create a Directory) gives the following:

mkdir [-pv] [-m mode] directory_name ...

Here’s how to read this command’s syntax, one item at a time (don’t worry about exactly what each item does; this is just for illustration):

· mkdir: First is the command itself.

· [-pv]: Anything in brackets is optional, and if possible, flags are run together in the syntax when using the command. So we know that the -p flag and the -v flag are both optional, and if you want to use them both, they can optionally be written as -pv.

· [-m mode]: Another optional flag is -m, and it’s listed separately because if you do use it, it requires its own argument (another string of characters, described in the man page). The underline beneath mode means it’s a variable; you have to fill in the mode you want.

· directory_name: This argument is not optional (because it’s not in brackets), and it’s also a variable, meaning you supply your own value.

· ...: Finally, we have an underlined ellipsis, which simply means you can add on more arguments like the last one. In this case, it would mean you could list additional directories to be created.

So the final command could look like, for example:

mkdir teas (all optional items omitted), or

mkdir -pv -m 777 a/b/teas a/b/nuts (all optional items included).