Published on MacDevCenter (
 See this if you're having trouble printing code examples

Learning the Mac OS X Terminal: Part 1

by Chris Stone

Editor's note -- After reading the chapters Chris Stone contributed to Mac OS X: The Missing Manual, I asked him to write a couple of articles for the Mac DevCenter because I believe that understanding the Terminal application adds value to Mac OS X. These tutorials give you a preview of what Chris has covered in the book.

The series continues in Automating Mail from the Mac OS X Terminal, Configuring Email from the Mac OS X Terminal, Customizing the Mac OS X Terminal, and Synchronizing Drives with Cron and the Mac OS X Terminal.

However, none of the first three parts of the series will work in Mac OS X 10.2 (Jaguar) or newer. Jaguar brought several major changes to the OS that require significant changes to the procedure. I'll be posting Jaguar compatible updates to these articles shortly.

Mac OS X’s Terminal application. There it sits in your Utilities folder, foreign and mysterious. You’ve heard that it's a portal to the new world of the Unix command line, a world where your flurries of mouse clicks can be replaced with a just few keystrokes.

But you’ve been wary of rushing into this new territory where the keyboard is king, concerned that without enough knowledge you might get lost, or stuck, or worse. Or maybe you're an adventurer who is just waiting to dive into uncharted waters.

This article is for you. Regardless of why you've previously avoided [localhost:~] yourname%, I'll show you how to take your first steps with the Terminal application. Then, I'll walk you through a tutorial that will accelerate your understanding of the Unix command line.

In Part 1 of this series, you’ll learn more about what Terminal does and get an overview of the tutorial procedure. You’ll then jump into the tutorial itself to learn the fundamental Unix commands you’ll need to know to get started with just about any command-line procedure.

Then, in Part 2, you’ll finish the rest of the tutorial, as well as learn a few more things you can do with the command line.

The command-line interface

The command-line interface (CLI) displayed in Terminal's windows provides access to the Unix shell, which is really just another way to interact with your Mac. The other method that you're probably more comfortable with is the Aqua interface. Aqua enables you to click on icons and menus, and to launch graphical applications by telling the Mac what to do.

The shell, on the other hand, allows you to type text commands to accomplish much of the same work. Typically, these typed commands launch tiny, single-duty Unix applications that do specific jobs and then quit. The shell itself is an application that plays the go-between for the commands that you enter and the Unix kernel at the core of Mac OS X. There are in fact several shells available. By default Mac OS X uses a shell called tcsh.

If you're curious about why you would want to use the shell in the first place, see the article Why Use a Command Line Instead of Windows? for more information about the CLI vs. the Aqua interface.

The procedure

Related Reading

Mac OS X: The Missing ManualMac OS X: The Missing Manual
By David Pogue
Table of Contents
Full Description
Sample Chapter

To help you learn the Terminal application more quickly, I'm going to introduce you to a Unix utility built right into your Mac OS X system. Working with this utility will help you get more comfortable with the core Unix commands.

Installed with Mac OS X is a mechanism that performs important fine-tuning of your system. It's called cron. By using this Unix task-scheduling utility, you can have your system regularly purge itself of outdated, space-hogging log files, update system databases so utilities like locate can work effectively, and do several other maintenance tasks that keep your system running lean and mean.

The cron utility fully automates this process, meaning that once everything is configured, the housecleaning will happen unattended as scheduled. The good news is that Apple has done the configuration for you. The not-so-good news is that they’ve scheduled these groups of tasks, or cron jobs, to run between 4:00 and 5:00 in the morning -- a time when your Mac is likely not even on! And if your Mac is never on during these times, these important tasks will never happen.

In this tutorial, I'll show you first how to modify the cron schedule, which is read from a file called the crontab, so that these tasks occur at more reasonable times. I'll then explain how to configure Mac OS X’s built-in mail server and the Mail application so that you’ll receive an emailed report every time the cron jobs run!

The tutorial

For this tutorial, make sure you're running Mac OS X 10.1 or newer, and that you’re logged in with an administrator’s account, though not the root account.

Open the Terminal program, which you'll find in the Applications_Utilities folder. Once launched, Terminal opens a single window displaying a greeting and a second line of text that comprises the prompt. With that window active, anything you type will enter just before the rectangular cursor that follows the prompt. After you type a command, simply press Return or Enter to run it.

The prompt shows the name of your computer (or rather its host name, which can vary), and then identifies your current working directory ("directory" is just the Unix term for "folder.") The current working directory is "where you are," that is, the location in your filesystem hierarchy that your next command will act on. Your initial working directory is always your "home" directory, which is identified in the prompt by the home directory shortcut character "~".

Terminal Window

To fully display the path to your working directory, use the pwd command: Type pwd (which means "print working directory," though it only displays it) and press Return:

[localhost:~] chris% pwd 
[localhost:~] chris%

Comment on this articleFor those of you trying the command line for the first time, how's it going? As for you experienced Unix users, how does the Mac OS X experience compare?
Post your comments

As you can see, pwd does its job by displaying the full path, or path name, to your home directory and providing you with a new prompt when done. This path name begins with the slash character, which represents the root or top-most directory of your filesystem. Note that directories that reside on your system disk do not include that disk’s name in their pathnames.

To act on a different set of files, you simply change your working directory using the cd command. We’ll first be modifying the crontab file, which exists in the /etc directory (normally invisible to the Finder). Enter cd followed by a space and the path name of the target directory, /private/etc:

[localhost:/etc] chris% cd /private/etc 
[localhost:/private/etc] chris% ls

Notice the change in the prompt reflecting the new working directory. If you’re curious about what your working directory contains, use the ls, or list command:

[localhost:/private/etc] 	chris%				ls
afpovertcp.cfg            	hosts				rc.common
appletalk.cfg             	hosts.equiv			resolv.conf
appletalk.nvram.en0       	hosts.lpd			rmtab
appletalk.nvram.en2       	httpd				rpc
authorization             	iftab				services
bootstrap.conf            	inetd.conf			shells
crontab                   	inetd.conf~			slp.regfile

As you can see, there are a lot of items -- quite a bit more than what’s shown here -- in /private/etc, including crontab.

The crontab file

The cron application launches automatically at system startup and runs continuously in the background executing commands as instructed by the crontab files. These files tell cron exactly what commands to run and when to run them. In fact, each user account can have its own crontab file. The system crontab found in /private/etc belongs to the super-user, or root account, and therefore can specify commands requiring the same total system access allowed to root.


Before you modify the system crontab, you should first make a backup copy in case you need to revert back to its default state. You’ll use the cp, or copy command, to do this, which lets you copy and rename a file in one step. Normally, to rename and copy a file into the same directory, you would type cp, followed by the name of the original file, and then the name of the copy:

[crontab: /private/etc] chris% cp crontab crontab.bak 
cp: crontab.bak: Permission denied

But hold on. It looks like you don’t have permission to write to the etc directory. In fact, only root can write to /private/etc. So, because you are not logged in as root, it might seem that there’s no easy way to write to this directory. But there is....


The sudo utility, for "substitute-user do," allows you to gain temporary root privileges on a per-command basis. To use sudo, simply preface the command you wish to run as root with sudo and a space, and sudo will prompt you for your password (not root’s). If you have administrator privileges, entering your password will run the sudo’ed command as if root were doing it.

Warning: Use sudo with care. You can easily make mistakes with sudo that could require complete re-installation of the OS to get going again. If that thought makes you queasy, it would be wise for now to use sudo only as directed in this article.

To perform the previous command successfully, preface it with sudo:

[office_g4:/private/etc] chris% sudo cp crontab crontab.bak 
[office_g4:/private/etc] chris%

Notes about sudo:

What you need to do next, then, is edit this system crontab file, and you’ll learn how to do it with a command-line text editor called pico. However, if you were to first examine the privileges for /etc/crontab, you would see that it’s owned by root, and only root has write privileges. Sounds like another job for sudo!


Of the several CLI text editors included with Mac OS X, pico is the easiest to learn. To open a text file in pico, simply enter the file name after the pico command. Used with sudo then, the command to edit the crontab file in the /etc directory looks like this:

[localhost:/private/etc] chris% sudo pico crontab

And this is what you’ll see when you run it:


The document’s text area lies between the black title bar at the top and the two rows of command prompts at the bottom. The Terminal window’s scrollbar won’t let you scroll through the document. Instead, you use the down-arrow to move the cursor down line by line, or use the Page commands.

All of the commands listed at the bottom are prefaced with the caret character ("^"), representing the control key. So for example, to go to the next "page" (actually screen-full) of text, press the control and "V" keys as indicated. For brief descriptions of all the commands, read the pico help file by pressing control-G.

The numbers in the circled area specify the time cron runs the scripts (there are actually three of them), and this is where you’ll make your changes.

Each of the three lines (numbered 1, 2, and 3) specifies one of the three scripts cron runs by default. Each script is different, performing its own appropriate set of maintenance procedures. The "daily" script, specified on the line labeled 1, runs once each day. The "weekly" script, specified on line 2, runs once each week. And the monthly script, specified on line 3, runs -- you guessed it -- once each month.

The first five columns or "fields" of each line specify at exactly what interval the script will run. The fields specify from left to right: minute, hour (on a 24-hour clock), day of the month, month, and weekday (numerically, with Sunday as 7). Asterisks used instead of numbers in these fields mean "every."

For example, line 1 specifies a time of 3:15 a.m.:

15	3	*	*	*	root	sh /etc/daily   2>&1 | tee /var$ …

Since the rest of the columns contain asterisks, the daily script (which is written in a file named on that line by its path name /etc/daily) will run at "3:15 a.m. on every day of the month, on every month, and every day of the week," that is "every day at 3:15 a.m."

Line 2 specifies that the weekly script runs at 4:30 a.m. on every weekday number 6, or Saturday:

30	4	*	*	6	root	sh /etc/weekly  2>&1 | tee /var$ …

And line 3 specifies that the monthly script runs at 5:30 a.m. on day 1 (the first) of each month.

30	5	1	*	*	root	sh /etc/monthly 2>&1 | tee /var$ …

By just changing these numbers, then, you can have these scripts run at more reasonable times. Of course, what’s "reasonable" depends on your own situation, so consider these factors when deciding:

  1. Choose a time when your Mac is likely to be on (and not asleep).
  2. Choose a time when a few minutes of background activity won’t disturb your work too much. On faster machines especially, the activity is hardly noticeable, but it could cause some stuttering if, for example, you happened to be watching a DVD at the time.
  3. Choose a time that is unique for each script. You don’t want to schedule scripts to run at the same time.

For example, these times might be good for a machine that’s only on during normal work hours:

*(Of course, the first of the month sometimes falls on a weekend or holiday, but for now, that’s the best you can do. You’ll find a work around to this problem in Part 2 of the article.)

To modify the crontab file to reflect these new times, use the cursor keys (the four arrow keys) to move the cursor to the proper field. Except for being unable to use the mouse, you’ll find that editing text with pico is similar to doing so with any GUI text editor. Use the delete key as usual, and type in the new values.

First, change the 3 in the daily script line to 17:

15	17	*	*	*	root	sh /etc/daily   2>&1 | tee /var$ …

Next, change the time in the weekly script line as shown, and the day from 6 to 2 (Saturday to Tuesday).

50	8	*	*	2	root	sh /etc/weekly  2>&1 | tee /var$ …

Finally, change the time in the monthly script line as shown:

30	9	1	*	*	root	sh /etc/monthly 2>&1 | tee /var$ …

Once you’ve made the changes, save ("write out") the document by pressing control-O. You’ll then be prompted to confirm the save. Just press Return to do so.


Finally, quit pico, by pressing control-X.

Once you’ve saved the crontab file, the new scheduling takes effect; there’s no need to restart. For now, you’ll not receive notification of the completed cron jobs, but in Part 2, you’ll learn how to make that happen, as well as learn more about the scripts themselves.

Chris Stone is a Senior Macintosh Systems Administrator for O'Reilly, coauthor of Mac OS X in a Nutshell and contributing author to Mac OS X: The Missing Manual, which provides over 40 pages about the Mac OS X Terminal.

O'Reilly & Associates recently released (December 2001) Mac OS X: The Missing Manual.

Return to the Mac DevCenter.

Copyright © 2009 O'Reilly Media, Inc.