Yet another Mac OS X command line introduction
By Mark Dalrymple, August 5, 2002
Want to dig even deeper? Post to the new MacEdition Forums (beta)!
You’ve got Mac OS X. You’re enjoying all the eye candy, licking the buttons, bouncing the dock icons about. You’ve read everywhere about the Unix ancestry of our new best friend, and you know that lurking somewhere is the Terminal program where you can delve into the command-line underbelly.
Why on earth would Mac fanatics of the 21st century dirty themselves using 1970s command-line technology? Because it’s fun! (No, really.) We’re all control freaks at heart and the command line is a great way to exert absolute control over your system. Once you master the command line you can brag about it at your local Mac Users Group.
One thing to keep in mind when learning the command line is that it is not a mystical and dangerous being just waiting to toast you with magic fire. It’s just a tool. Like any power tool, you have to be careful or it can bite you, but show the tool the proper respect and it will serve you well.
The command line is a direct interface to your system. You tell the system what to do and it’ll happily do it. You need a different mindset when using it: “remember and type” versus the usual “recognize and click” Mac style. Some folks have the mental makeup to really absorb this stuff, and some folks don’t. We’re all wired differently, and there’s no shame if the command-line Unix ideas don’t come easily.
One thing that I’ve noticed with many other “intro to the command line" works over the years is that they’re very abstract: “Here’s the concepts of how this works,” or “Here is a pipeline,” or “Metacharacters and shell globbing." I know my brain glazed over when I first read about and learned Unix back in 1990. The best thing to do is learn something useful to do, and go from there.
Space, the Final Frontier
“Help! My disk is filling up, and I don’t know where all the space is going!” I don’t know about you, but this happens to me all the time. Even with today’s massive storage capacities I keep riding on the edge of filling up my disk with loads of junk. You can use the Finder to explore your disk to see who the real disk pigs are, but I find that slow as the Finder laboriously churns through folders determining their size. So, let’s use the command line.
First, you’ll need to fire up
program is located in the Utilities folder of your
Applications folder. Start it up, and maybe keep it in
your dock so it’s always handy. My
at the top, just below the Finder.
You’ll probably see something like:
Following the % is the text cursor (by default a little rectangle, but you can change that in the Terminal preferences). This is the prompt, where you type in your commands. Terminal.app is running a second program called a shell which is what is interpreting your keystrokes and ultimately displaying information back to you. When you type in a command the shell runs the program specified by the command. The text output of that program (if any) gets printed right below where you typed. You then get another prompt so you can then type another command, and again, and again ...
For the examples below, I’m going leave off the extra jazz before the percent sign. That way you don’t have to wade through extra crud when reading.
Okay, disk space. The first thing I do is see how full my disks are.
df command (shorthand for Disk
Free) shows statistics about the amount of free disk space on
% df Filesystem 512-blocks Used Avail Capacity Mounted on /dev/disk0s9 39065400 35600912 3464488 91% / devfs 63 63 0 100% /dev fdesc 2 2 0 100% /dev <volfs> 1024 1024 0 100% /.vol automount -fstab  0 0 0 100% /Network/Servers automount -static  0 0 0 100% /automount
There’s a whole lot of stuff, with most of it being pretty peripheral to the discussion here since the first two lines are what’s actually interesting. The first line are headers for the columns so you know what they are: the device name of the file system, how many blocks total the device has, how many blocks are in use (allocated to files and directories), how many blocks are available, how much of the disk is being used and where that device lives in the file system. In this case, the first line of real information:
/dev/disk0s9 39065400 35600912 3464488 91% /
... says that my only disk has 39 million blocks, 35 million are used, 3.4 million are available and that I only have 9 percent of my disk space left (see, I told you I’m a disk pig).
For inscrutable historical reasons,
df reports disk
usage in 512-byte blocks. I don’t know about you, but I think
better in kilobytes (1024 bytes). Almost all commands (like
df) can be decorated with flags, also called arguments
(computer people like to argue, hence the name). So, we tell
df to display its output in kilobytes by using the
% df -k Filesystem 1K-blocks Used Avail Capacity Mounted on /dev/disk0s9 19532700 17832524 1700176 91% / devfs 31 31 0 100% /dev fdesc 1 1 0 100% /dev <volfs> 512 512 0 100% /.vol automount -fstab  0 0 0 100% /Network/Servers automount -static  0 0 0 100% /automount
Now note the first lines again. It’s now much easier to see that I have a 20GB disk, I’ve used 17GB and I have 1.7GB free. (But I still only have 9 percent free. Oh well.)
Okay, I now admit I have a problem. Since my machine had plenty of space when I first got it, it’s logical to assume that the disk space being consumed is where I put my personal files, which is in my home directory (aka the home folder. I’ll now refer to “folders" as “directories,” since that’s the Unix lingo).
du command (short for Disk
Usage) will show you how much space a file is consuming as well as
how much space a directory and all of its contents is consuming. When run
du is annoying, so we’ll decorate the
command with two flags:
-s will give a
-k will show the
disk space consumption in terms of 1K blocks. (Otherwise it will act like
df and return results in terms of 512-byte
blocks.) So, you can do:
% du -s -k 1320332 .
That means that my home directory’s contents are eating 1.3GB of disk space. (I’ve got a bunch of developer tools installed elsewhere that are eating up a lot of space, but I figured I’d keep things simple by just looking at home for my space pigs.)
Since command-line Unix geeks don’t like to do a whole lot of typing (as
evidenced by unpronounceable commands like
df), you can
combine the flags into one group:
% du -sk
You can stack the flags up so long as things make sense to the command. If the command can’t understand what you’re trying to say, it’ll complain.
So, knowing that my home directory is 1.3GB is all well and good, but I
find out who the real culprit is. You can give file and directory names
du, and it will tell you the consumption for only
what you tell it to:
% du -sk Library 472 Library
So Library is consuming 472K. You can specify multiple file names:
% du -sk Pictures Library 140 Pictures 472 Library
Library: 472K. Pictures: 140K. Film: at eleven.
You can also use the special character * to indicate “all files and
directories at this level.” (Note for DOS folks: Using
*.* out of habit will actually ignore any files that
don’t actually have a dot in them.)
% du -sk * 764496 ClipArt 4 Desktop 45428 Documents 472 Library 0 Movies 0 Music 140 Pictures 0 Public 32 Sites 509756 downloads
Hmmm ... ClipArt and downloads look pretty piggy.
For a small directory like my home, it’s pretty easy to visually scan the output. But wouldn’t it be nice if we could have stuff ordered by the number of KB consumed?
Pipelines to the rescue!
The whole Unix command line philosophy is having a huge pile of simple utilities and hooking them together. Picture a pipeline of water going into the factory of your favorite artificially sweetened carbonated beverage:
- water is pumped in from the river or stream
- pollutants are removed (pesticides, candy wrappers, small rocks)
- artificially sweetened syrup is poured in
- the mixture is stirred
- carbon dioxide gas is added
- the refreshing beverage is put into an appropriately shaped collectible plastic bottle
Unix commands are like this. A command generates a stream of text
somehow, like a listing of files in a directory, or in our case the
output of the
du -sk. You can then tell the system
to have other commands transform that stream. They take the output
from the command ahead of them in the pipeline, modify the information
(add stuff, remove stuff, move stuff around), then send it to the
command behind them in the pipeline.
So, for us, we want to sort (numerically) the results of
du -sk. Using the | (pipe) character, we string the
% du -sk * | sort -n 0 Movies 0 Music 0 Public 4 Desktop 32 Sites 140 Pictures 472 Library 45428 Documents 509756 downloads 764496 ClipArt
Pretty spiff. So, let’s pull the command apart:
du -sk *
Give us disk usage, summarized by kilobytes. The results aren’t guaranteed to come out in any particular order. Next:
Take the output of
du -sk, don’t display it in the
Terminal window, but instead, send it to:
... which is the
sort. (Sometimes the Unix
folks use actual English words for commands.) The
-n flag says to sort the lines numerically.
-n, it will scan the
beginning of lines looking for numbers. Upon finding the numbers,
it’ll arrange the lines accordingly.
You can further decorate the command and add the
to sort in reverse order:
% du -sk * | sort -rn 764496 ClipArt 509756 downloads 45428 Documents 472 Library 140 Pictures 32 Sites 4 Desktop 0 Public 0 Music 0 Movies
Cool. It works.
For 10 files, it’s pretty easy to see everything in one screenful. If
you have a ton of files and directories but only want to see the two
largest consumers of disk space, you’ll have a lot of output you’re not
interested in. The
tail command will let you
ignore everything except the last couple of lines. We’ll just add it to
the pipeline (the one where we don’t reverse the sorting). Here’s a
command to show the two biggest disk consumers:
% du -sk * | sort -n | tail -2 509756 downloads 764496 ClipArt
tail (another Real
Word) to ignore everything but the last two lines. If you don’t give an
tail will show the last 10 lines. Given
that there are only 10 files in my home directory, using an unadorned
tail would be silly. You’re also not limited to 2 or
10. You could do
tail -37 to see the last 37
Mark Dalrymple (firstname.lastname@example.org) 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.