Using the OS X Leopard Command Line
This chapter is from the book
This chapter is from the book
This chapter is from the book
If you're a casual Mac user, or even if you're a hard-core Linux or Unix user, there are a few things about Mac OS X and the particular flavor of Unix under its candylike shell that might catch you off guard. Files and folders behave in rather different ways when you're addressing them with textual commands than when you're shoving them around with your mouse. Not only do they look different, they act different, too. You might even say they "think different."
The shell, which is what we call the command-line environment displayed by the Terminal application, is an austere and cryptic piece of software—about as un-Mac-like as it can possibly get. By the end of this book, you'll have found all kinds of uses for it—tricks that weren't otherwise possible using the graphical Aqua interface. But there's a steep learning curve, particularly for readers who have never dabbled in Unix before, and there are a few things you're going to have to know about how your files work in the shell before you can really start ordering them around.
Everything Is a File
Your Mac is designed primarily to show you your documents, folders, applications, and other items in neatly ordered windows, with pretty icons next to them to help you differentiate them based on their type. You can open Finder windows that show you each item's Kind in a column, distinguishing your Photoshop images from your Word documents and your folders and applications. Mac OS X even has "bundles," which are special folders full of executables and other items masquerading as single monolithic files in the Finder, which you'll learn more about in Chapter 5, "Using the Finder." At the graphical level, your Mac is full of all kinds of items that each get their own unique look and descriptive vocabulary.
Not much of that matters at the command-line level. Your shell doesn't see a folder differently from how it sees a Word document; they're both just "streams of bits with names" as far as it's concerned, and in its 1970s-era worldview that's all that matters. The only thing distinguishing a folder (or directory) from a file is that the bits in it describe links to other files that the operating system should interpret as part of that folder, rather than the binary or textual data stream that make up a file's contents—but to Unix that's trivia. If you use the ls ("list") command in the shell to list the files in a folder, you'll just get a list of names—no icons, no turn-down arrows, no clues to help tell you that some of the things you're looking at are files and some are folders, applications, or what-have-you. (There are some options you can give to the ls command to make it smarter about how it lists the items, as you'll see later; but that's a courtesy that Unix only grudgingly grants.)
In the Unix world, everything's a file, including such oddities as running processes and network connections and attached devices, and you interact with them all in pretty much the same way, using the same commands for everything (with a few exceptions, like the mkdir command). I point this out to make you aware that if you see the command-line examples in this book refer to "files," it means "files, folders, and any other discrete pieces of data." If a command makes a distinction between regular data files and other kinds of items, I'll say so; but otherwise, you can generally expect that a command will work the same on one kind of item as on another, because it'll see "files" with as little discrimination as Unix does.