BOLTS : Click to return to MacEdition homepage

Yet another Mac OS X command line introduction (Part 4)

Back to parts: 1, 2, 3.

By Mark Dalrymple, August 5, 2002

Don’t find it, grep it

Other stuff to look at:

  • MacObserver has started a Command Line 101 series which goes into more depth of many topics we’ve just touched on here.
  • O’Reilly has an ongoing series of articles that are somewhat on the advanced side, such as editing crontab files, using the pico editor, and pulling apart MP3 music streams.
  • Mac OS X Unleashed has a couple hundred pages on using the command line (and some good chapters on a lot of other stuff, including NetInfo). It’s also big and heavy enough to weigh the dog down in case a tornado rips through the area.

There are also tons of Unix and Linux books out there which have information on using the command line. Many of the tools are universal between Unix systems, so much of the information should be readily transferable.

Your local Mac Users Group probably has like-minded folks learning the command line, or know it already from a previous life.

You might also want to consider looking up a local Linux Users Group (LUG). has a searchable LUG directory. Many LUGs welcome Mac OS X folks since the OS X Darwin underpinnings are open source (like Linux). You may also find that several members already have iBooks and are running Linux or OS X. Hobnobbing with command-line geeks in person can be fun.

Enough of pagers. Now for searchers. Probably the quintessential Unix command is grep. Which is an acronym of technobabble, so I’ll just say it’s short for “grep." grep will look at a pipeline (or in a file, if you give a name on the command line) for a pattern of characters. So, if we were looking for files in /usr/bin that contain “mail" in the names (well, okay, this little article isn’t all that useful anymore, but you’ve already read this far, so you might as well stick around), you’d do something like this:

% ls -1 /usr/bin | grep mail

Lastly, you can send the output of a command or a pipeline to a file through the magic of redirection. If you follow a command with > file-name, it will write all of the output to that file (obliterating the file if it already exists). So:

% ls -1 /usr/bin | grep mail > mail-related-commands.txt

... which produces no output since it all goes into the file.

You can then look at the file in the program, Project Builder, your favorite word processor, an editor run from the command line, or you can read the file into the terminal window with the cat command (which is short for concatenate, some geeky word that involves attaching chunks of text together):

% cat mail-related-commands.txt

With the same output as the grep sample above.

Since cat is just another Unix command-line command, you can use it in pipelines too:

% cat mail-related-commands.txt | grep f

That is, only display the lines that contain the letter ’f’.

Finding out about commands

The command line is great once you know what commands you want to run. One of the hardest parts about mastering the command line is learning all these commands and learning where to find what you need. The man (short for manual, as in the documentation nobody ever reads) will give you documentation on a given command:

% man du
DU(1)                       System Reference Manual

      du - display disk usage statistics

      du [-H | -L | -P] [-a | -s] [-ckrx] [file ...]

  The du utility displays the file system block usage for each file argu-
  ment and for each directory in the file hierarchy rooted in each directo-
  ry argument.  If no file is specified, the block usage of the hierarchy...

... along with a prompt from less, so you can page back and forth in the docs looking for what you want.

You can decorate man with the -k flag (k for “keyword"). In that case, man will look through its little database, and return commands that have something to do with that. For instance:

% man -k disk
calloc(3)                - allocate clean memory (zero initialized space)
dbsym(8)                 - copy kernel symbol table into db_symtab space
df(1)                    - display free disk space
expand(1), unexpand(1)   - expand tabs to spaces, and vice versa...
sync(2)                  - synchronize disk block in-core status with that on disk
sync(8)                  - force completion of pending disk writes (flush cache)
update(8)                - flush internal filesystem caches to disk frequently
vnd(4)                   - Vnode Disk Driver

(I had a total of 22 matches.) Usually, scanning through the output will give you interpreting commands to try. Like these two we saw before:

df(1)                    - display free disk space
du(1)                    - display disk usage statistics

If you want to be fancy, you can use the apropos, which is identical to man -k.

That about does it for our “brief” introduction to the command line. Hopefully you learned some new techniques, or at least got over the initial fear of stepping into this very foreign world. The command line and the Unix shell are very deep subjects with lots of layers of usefulness and complexity that have built up over the years. For instance, the grep command can look for patterns of arbitrary complexity. You can edit text interactively in a terminal using vi or emacs. You can specify which files a command operates on with patterns. There are different kinds of shells you can use which have different features. Shells have full-featured programming languages built in that let you write scripts to automate stuff.

You can control file ownership and access permissions. Filenames can be used directly by various commands rather than injecting text into the pipeline with cat. You can create variables in your environment that can affect the behavior of programs you run. In addition to the in and out streams in a pipeline, there is a third stream where error information comes from, and you can redirect that to a file separately from the main information. The Unix command line has been around for a long time, and has grown a lot of features over that time. But this is enough information to get you started on doing useful stuff in this brave new world.

Mark Dalrymple ( has been wrangling Mac and Unix systems for entirely too many years. If you need a custom Mac OS X application developed, boing on over to Borkware and we’ll talk.

E-mail this story to a friend