Interacting with Unix: Basic Unix Commands

Getting Started with the Command Line

If you're not familiar with Unix, you've probably heard and read enough to have developed any number of preconceptions regarding what using it will be like. Almost all of them are probably at least a bit intimidating. You've probably heard that Unix commands are cryptic and that the learning curve is steep. Even worse, it uses a command-line interface you've actually got to type at the thing to tell it what to do, and we all know how archaic that mode of controlling a machine is.

It might be archaic, but that does not mean that there's anything wrong with it or that it's not the best way to accomplish certain tasks. We know many of you poked fun at that other operating system for years because its unfortunate users had to type to make it work. Don't worry; we've laughed, too. You're just going to have to be courageous and admit that you've used the keyboard in the Mac OS Finder to do things such as jump a Finder window to a file with a particular name. The mouse is a wonderful tool for doing things where the brain's visual processing machinery can come into play. The keyboard is also a powerful tool for other types of interaction, and it would be silly to intentionally restrict yourself to only one type of interface when other complementary interfaces are available. In many ways, what Apple has given you is analogous to being provided with a high-end sports car, and a fully equipped machine shop and garage to work on it. If buzzing around in the fancy car is your pleasure, you are free to do so without ever opening the hood. On the other hand, if you feel like working on the engine, all the tools are there to enable you to further customize and enhance your ride to your heart's content.

Regardless of what you've heard, the idea that learning and using Unix will be fun and rewarding is likely to be furthest from your mind. We hope that in this and upcoming chapters, we'll be able to convince you differently. If we can't, don't worry. Nothing about Mac OS X requires you to learn and use anything other than the graphical interface that we've already covered. You can live with your Mac OS X machine, use it for the same type of applications you always have, and love it in all its "nontypishness," without ever having to learn any of this Unix stuff. However, if you want to learn how to make your machine even more powerful, make yourself more productive, and customize everything to an exquisite extent, give this command-line stuff a try.

CAUTION

Having just told you that we think you'll like the Unix side of your machine if you give it a fair chance, and encouraged you to try it out, we'll turn around and caution you about its use. Unix is not for everyone. Although we'd love to see every Macintosh user graduate to the power available in the BSD subsystem, we can't avoid the reality that Unix is more complicated and powerful than some users will ever want to use. Just as some of us are safer not owning super-fast sports cars, some are less a threat to ourselves and others if we don't have a big box of firecrackers, and some would be better off if we couldn't buy donuts by the dozen, Unix is just too much for some people. It might be too much power, or too much flexibility, or too much information to remember, but Unix seems specially designed to create a user who epitomizes the phrase "knows just enough to be dangerous."

Evaluate your needs honestly. We're firmly convinced that everyone can learn Unix, and everyone can use it safely, but the reality is that not everyone will. If you're hesitant about trying out the Unix side of your new operating system because you think it might be too difficult, we suggest that you give it a try because we think we can convince you that it's not as tough as you think. If you're not sure that Unix is a good match for what you do, you might be right: It might be better if you use Mac OS X as the super-stable, more flexible operating system on which to run your GUI-based programs, and leave the BSD subsystem alone.

Understanding the BSD Philosophy

One of the complaints you might have heard from people regarding Apple's new operating system is that it is based on immensely old operating system technology. They're right! The roots of Unix lie almost in the roots of modern computing itself. The thing that they're wrong about is their claim that this is a "Bad Thing." Unix development started more than three decades ago, and the operating system that you can use today is the product of the work and improvements of thousands upon thousands of developers. Along the way, Unix has picked up some powerful design concepts and some wonderful solutions to problems common in the computing world.

Much of the "Unix way" is based on the idea of abstracting interfaces into the simplest possible terms. Initially, this was simply because the operating system was experimental, and the simplest possible interface one that wouldn't need to be fiddled with later was the most expedient to construct. Over time, this "do it the easy way" methodology has evolved into a powerful design concept: abstraction. This concept will be mentioned time and again as it makes its appearance in different topics throughout the book.

As an initial explanation, though, an example provides immediate understanding. Among many other concepts, Unix abstracts the notion of things that can be read from, or written to, as files. To Unix, everything from which data can be read is treated as though it were a file, and everything to which data can be written is treated as though it were also a file. Why? Because after you've developed an in-OS methodology to control reading and writing to files, it's a nuisance to have to implement almost identical methodologies for reading and writing to the network, or writing data to printers, or reading data from the keyboard. Instead, it's considerably easier to write an abstraction layer that talks to the particular device and makes it appear to the operating system as just another file. If you make your printer look like a file, printing is simply "writing to a file" for any application. If you make your keyboard input look like it's coming from a file, any application can automagically accept input from either the keyboard or an actual on-disk file, without knowing the difference.

What starts as a time-saving implementation turns into a powerful interface feature, allowing the addition of arbitrary devices, without needing to implement new OS features just write something that makes the device "look like a file," and suddenly the operating system can use it. This notion of abstraction ends up being powerful for the end user, and similar abstractions are pointed out in the sections to come.

More information on Unix and its role in computing can be found at http://www.macosxunleashed.com/unixhistory.html.

Additionally, the Unix design philosophy drives programs that are used in day-to-day interaction with a Unix machine to be small, single-purpose, and non-overlapping in functionality. The presence of a vast array of these single-purpose programs, designed so that they can be combined in near-infinite combinations, allows the user to construct customized solutions for most any problem. The necessity for some programs to provide more complicated functionality, requires them to be less-single purpose, and to allow somewhat more overlap. Finally, just as in other operating systems that you're used to, there are programs that are large, multifunctional, and monolithic. Typically, Unix users think of the small, single-purpose programs as commands, and the large, multifunctional programs as applications. Although they're all programs, the term program itself is frequently reserved for a program that doesn't fit the description of a command or an application. This somewhat muddy semantic distinction between types of programs might seem confusing at first, but as you become more comfortable using Unix, it will make more sense to you. As an example to get you started, you can think of a Unix command as a small program with a single function such as listing files. A Unix application is typically a much larger program, perhaps something like a word processor or a web browser. Moreover, although both are programs, the term program itself is infrequently used to describe anything that falls into either of these categories.

Thankfully for the beginning Unix user, making complete sense of the semantic distinctions isn't necessary for anything other than conversing with other Unix users.

Finally, it is important to understand that almost nothing to do with the Unix way of thinking about things, BSD design philosophy, or the command line, has anything to do with Apple's Tiger specifically. The command line sections of this book are not about Tiger's command line, or even Mac OS X's command line particularly. We're using Tiger and other versions of Mac OS X as our primary examples, but the Unix shell is the Unix shell, is the Unix shell. You could apply 99.9% or more, of this information directly to Linux, or Sun's Solaris, or any of a dozen other flavors of Unix, or the information from their related reference materials for working with Tiger. As a matter of fact, you'll find examples here that span from the most recent beta release of Tiger, to output from a version of Unix that Sun Microsystems hasn't produced since 1993. Unless you're incredibly astute, you won't be able to tell the difference (which is entirely in the detail of dates displayed for some files in the output). Apple has applied its own little tweaks and flavor to things, but when looking at these examples, it's important to concentrate on the ideas. The details are window dressing.

Using Terminal to Access the Command-Line Interface

The Terminal program, found in the Utilities subfolder of the Applications folder, is the primary method for communicating with the BSD subsystem of the Mac OS X installation, via the Unix command line. Some tricks and nifty applications are already appearing to insulate you from the need to work with the command line for some applications that are essentially command line based. We cover these as well, but the Terminal itself will probably be your primary mode of interaction.

Simply put, Terminal.app, which appears to the Finder as simply Terminal, and being an application bundle, to the command line as a directory named Terminal.app, is a virtual terminal by which you can type commands to your machine. It's the software version of what used to be implemented as a dedicated hardware device, one that understood how to display data and put it in specific positions on a screen. A terminal itself isn't particularly interesting but provides the mechanism for communication between you and programs that are more interesting to talk to.

Terminal itself has a number of useful preferences that you can set that modify how several things in this and subsequent chapters work, but before we go into those details, let's see just what Terminal can do for you. The preferences for Terminal, as well as some of the additional functionality available through the menus are covered at the end of this chapter.