by Kyle D'Addario
& Wincent Colaiuta
Mac OS X's Command Line -- What's All The Fuss About?
May 11th, 2001
For many years Macintosh users have been restricted to one primary method of interacting with their computers: the graphical user interface, or "GUI." With Mac OS X they are granted easy access to a powerful alternative for the first time: the command line interface, or "CLI." Thanks to the BSD Unix underpinnings of the new OS, a CLI is only a few clicks away -- it's just a simple matter of launching the "Terminal" application in the Applications/Utilties folder. We've already made use of the CLI in previous Hot Cocoa columns.
Debates have long raged between advocates of CLIs and those of GUIs (a good source of info on GUI design is David K. Every's MacKiDo Web site). On one side, staunch CLI aficionados argue that there is nothing that can't be done with a CLI and that certain operations are undeniably faster. On the other, GUI devotees point to the Mac's ease of use and take a line of argument very similar to that of the CLI cognoscenti: they say there's nothing a GUI can't do and there are some things that are much easier and faster.
In this column I'll make my own argument for why the inclusion of a CLI in Mac OS X is a good thing. When you provide users with multiple ways of achieving the same thing then the flexibility and efficiency of the system increases. By adding a CLI to the Mac OS's existing GUI Apple has offered us more ways of doing what we want: we can work faster, better, and in a more complex way. By learning both the CLI and the GUI we'll always be able to choose the best tool for the job. To help us along this road I'll present a few examples of CLI usage that show its unique strengths.
The power of piping
The CLI permits the piping of output from one command to another using the "|" operator. A command line like "a | b | c" effectively means: run the command "a", take the output of "a" and feed it to command "b" for processing, and finally take the output of that and pipe it to "c." A graphical analogue to this process might be, for example, grabbing some picture data from a scanning application, importing it into Photoshop for processing, and then using the resulting image in a web-design program.
It's often hard to achieve this level of automation with a GUI in practice, but with the CLI it's easy. A real-world example is a command like:
ls -laF | more
What this does is get a long directory listing (the "ls" command) and feed it through the "more" command, which is used for displaying screenfuls of text in a user-friendly way (permitting scrolling forward and back, searching and other features). More advanced use of pipes means that quite complex operations can be performed with a single line of typing.
One more example; in preparing this article I was curious to see how many times I'd used the "sudo" command lately. All I needed to do was type "history | grep sudo | wc -l" (which translates to: "print a list of all the commands I've type recently, show me only the lines which contain the word "sudo," and rather than show me all the lines just print a count of them").
Command line interfaces can use wildcards to specify multiple files in a single statement. The most common wildcard is the "*" (asterisk) character, which can be used to represent any text. Consider the following command:
ls -laF red* | grep /
The "ls" command lists all files in the current directory, and I have added "-laF red*" which says I only want the ones that begin with the word "red." Notice how I've used the pipe (|) operator to send the listing to the "grep" command, which will then eliminate all lines except for those that contain the slash (/) character. In this way, I've created a one-line command that lists all the folders in the current directory starting with the word "red". (Incidentally, there are other ways you could do this, but I'll leave that as a homework task...)
For a more useful, real-world example, consider that you might want to move all the JPEG images in the current directory to your home directory. Instead of drag-and-dropping them in the Finder, you could use the following command to easily move them into your "Pictures" folder with a single line:
mv *.jpg ~/Pictures/
Because the CLI is text-based, you can access it from anywhere. Thanks to Mac OS X's built-in SSH capability, you can connect to your machine from anywhere in the world and type commands in as though you were sitting in front of your own keyboard. Although there are methods for controlling a GUI over a network, these implementations find it hard to keep up with the raw simplicity and speed of a CLI, especially when the distance across which data must be sent is large.
Context-independent file access
To copy files with the Finder you need to have both the source and destination folders in view at once. This can be problematic because it requires you to maintain a compromise between keeping your folders in view at all times (which is convenient but results in screen clutter) and keeping your folders out of sight (which reduces screen clutter but requires a time-consuming search for the right folders before a copy can be undertaken).
In contrast, with the CLI you can access any file or folder at any time without having to worry about the context that you are in. This is because you can specify full file paths in your command. What if I want to make a backup copy of my httpd.conf file? Do I have to worry about being in the right source or destination folder? No... It's just a simple matter of typing:
cp /etc/httpd/httpd.conf ~/Documents
Thanks to the CLI's tab completion feature, the typing is made even easier. All I need to do is start typing the first few letters of a file and then hit tab and the CLI will auto-complete the name for me if at all possible. The above line copies the httpd.conf file into my Documents folder no matter where I am in the file hierarchy.
Easy user-level multitasking
What do you do in the GUI if you want to access another user's files? What if you want to do something that only an administrator can do but you're logged in as an unprivileged user? In the GUI, often the only choice is to log out and log back in again as the right user.
In the CLI it's easy to become another user (provided you know the right password) and easy to have tasks for multiple users running at the same time. Typing "su," for instance, and entering the root user password enables you to temporarily become "root." Typing "su user2" would enable me to become "user2." provided I knew the password. Consider the following example, which shows another way of running something as an administrator:
sudo chgrp admin .
The "sudo" command enables me to execute the following command as the superuser, in this case allowing me to change the group setting of the current directory to "admin."
Because CLI windows can be made small, I can have many of them open at one time, running multiple commands for different users if I see fit. There's nothing to stop me from being logged in via a CLI to multiple machines across a network all at once, in fact.
The features that I have discussed in this column are only a small sampling of the special capabilities of the CLI. I for one am very glad that it made it into Mac OS X (Apple's initial plans were to make the CLI unavailable to end users). By adding this powerful avenue for user-to-machine interaction Apple has made it possible to do certain things much more quickly and easily, and to do some things that weren't possible at all with the GUI. The best thing is that while Mac OS X users never have to use the CLI unless they want to, for those who are curious it is at their disposal.
And this is probably only the beginning; expect to see still more ways of interacting added as speech recognition technology improves and other methods make their entrance into the mainstream computing arena (such as vision tracking and the positively sci-fi "mind" control). The more ways that users have of communicating their intentions to the computer, the more efficiently and powerfully they will be able to work. The addition of a CLI to the Mac OS is a significant step in this direction.
You are encouraged to send Richard your comments, or to post them below.
Most Recent Hot Cocoa Columns
Mac OS X & Firewalls: Part One - The Basics
Console Yourself: Understanding Mac OS X Logs
Making NFS Work On Mac OS X
Hot Cocoa Archives
Back to The Mac Observer For More Mac News!
Kyle D'Addario is the assistant editor of The Mac Observer and has logged about as much time on Mac OS X as is humanly possible. Kyle studies Computer-Mediated Communication, whatever that is, at the graduate level, and was a founding member of the original Webintosh team.
Wincent Colaiuta runs Macintosh news and criticism site, wincent.org, and joined The Mac Observer team as a contributor in March 2001. He has worked with computers since 1984, and his interests in that area include Macs, PHP programming and security.