Yet another Mac OS X command line introduction (Part 4)
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
picoeditor, 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). Tux.org 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 fetchmail formail mail mailq mailstat movemail procmail rmail
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 Edit.app 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
fetchmail
formail
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(1)
NAME
du - display disk usage statistics
SYNOPSIS
du [-H | -L | -P] [-a | -s] [-ckrx] [file ...]
DESCRIPTION
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.