The Terminal: Why?
Volume Number: 21 (2005)
Issue Number: 2
Column Tag: Programing
Mac In The Shell
by Edward Marczak
The Terminal: Why?
Love it or leave it!
You've got a fancy Aqua GUI in front of you (errr...if you have the print magazine in front of you,
look at your OS X box now), why would anyone use the command line? The command line!?! We're here
at MacTech because we use a Mac - the computer that popularized the GUI!!! The computer that said,
"CLI? Gag me with a spoon!" (well, it was California in the 80's). However, despite Apple
initially eschewing a command line altogether, the CLI has survived. There's a lot of power there,
and OS X lets you tap into it. Furthermore, anyone can fire up a GUI utility and make some changes.
But if you want to impress your date, you have to learn some command line tricks.
If you're a bit more of a CLI veteran, but are coming from a different platform, you may simply
want to jump down to 'Apple-fying the CLI".
I work with a broad spectrum of people that reign over technology in some way: from low-level
hardware and software hackers, to networking experts, high-level FileMaker developers and
GUI-rangers. These people have all learned, or come close to mastering, the command line, and are
better for it. I've grown up in a world of teletypes, Commodores, IBMs, Unix boxes, Apples, Netware
servers, DOS and Windows environments. All of these machines started with a command line (and some
ended there). In the timeline of computing, the GUI was an afterthought. Not for the Mac, of
course. But go back to an Apple II, (if you've got one laying around!) and you'll find that when
you boot up, you're presented with a ']' prompt and blinking cursor. Since this environment has
been around so long in the Unix world, it is very well thought out and very mature. But it's
certainly one of the reasons people not-in-the-know would panic when they'd turn on a computer. What
do I do? It's just sitting there blinking at me. Will I break it if I type the wrong thing?
The Mac OS tried to end all of that command line fear and present a graphical interface at boot
time that made people feel comfortable. They did a great job. But fast-forward to now, and Apple
is singing a slightly different tune. However, I find many people who are dyed-in-the-wool Mac
users simply pretend that Terminal.app doesn't exist.
Here we are, and there's a command line in a Macintosh operating system. They just couldn't keep
it out of there. In all honesty, if it weren't in there, I'd be writing for a Linux magazine right
now. As a techie, and someone who likes (and many times needs) to troubleshoot, there was no bigger
breath of fresh air when I fired up Terminal.app under OS X (10.0 beta, on my Powerbook G3). I
immediately typed 'ping 192.168.30.1' for the network I was on and saw the replies come back. Wow,
Apple did it. Keep Word. Keep Safari. Heck, even keep Quake and Tron 2.0, I don't want a computer
without access to the command line. But why?
I mentioned the power that lies in the terminal, what is that all about? Why is it so much more
powerful? Firstly, you can typically type more quickly than you can mouse around. From time to
time, I see people launch Calculator and click on each number rather than use the number pad on
their keyboard. Doing that just doubles the time required. Secondly, as people like to
customize their GUI (I'll admit that when I work on other people's machines and I find the dock on
the left it drives me a bit batty...) and GUIs change over time (look at the differences going from
10.0 to 10.3), the CLI is pretty much the CLI. Of course, it can be customized, but it's usually
done in such a way that it doesn't change the way standard utilities run. Third, it gives you a
consistent way to administrate a machine. Fourth, it gets you a little closer to the operations of
the machine. Have you ever had the GUI lock up on you? I have. But everything else was still
running and I was able to console in and reset the machine gracefully. Fourth, and most
importantly, Apple lied to us! When OS X shipped, we were told that we'd never have to see a
command prompt if we didn't want to. OK, perhaps not. But that stopped us from doing certain
things with our machines. While the entire situation is getting better, there are things you can do
in the terminal that there is simply no GUI equivalent for. With those notes, let's get familiar
with Apple's Terminal.app, starting with the configuration that ships with OS X 10.3.
Launch Terminal.app from /Applications/Utilities/Terminal. Perhaps the fact that you find the
app in 'Utilities' rather than 'Applications' is something that scares people right away, as if it's
not something one should normally run. Figure 1 shows approximately what the default terminal looks
Figure 1 - A default
terminal in OS X (Panther 10.3.7)
I say 'approximately' because you will have some differences. Of course, the time of your last
login will be different. Unless you've already changed it, your "message of the day" will still
read "Welcome to Darwin!" The next line is your prompt, and it is generated at run-time.
'Jack-Kerouak' is the name of my machine (because, if you must know, it's a laptop and I'm always
"On the Road"), and you'll have the host name of your machine. The "~" shows my current path, and
by default, we start out in our home directory (which is represented by the tilde). "game" is the
short name of the account I'm logged in as (remember: Quake and Tron 2.0!), and you'll have your
user name. Then, there it is, the cursor. Patiently waiting for you to type.
Black text on opaque white. Boring. Lets go check our window settings. Choosing the
"Terminal->Window Settings..." menu gives us some ways to modify the look and behavior of the
terminal. Figure 2 shows the first of several preferences that can be changed in the 'Terminal
Figure 2 - Terminal
Of course, these are all preferences, and are unique to each individual. I'm going to share how
I like my terminal to behave, but by all means, choose what makes you most comfortable.
The first set of preferences, "shell", gives us one option: choose what to do when the shell is
done. I think I've only had one occasion to keep it at the default, so I immediately change this to
"Close only if the shell exited cleanly."
The "process" preferences work perfectly at "prompt before closing window if there are processes
other than:". I like being prompted as little as possible for anything. The "emulation" settings
have good defaults, but may need to be tweaked for a particular case. The only thing I do here is
check the "option click to position cursor" checkbox, despite actually using that function very
The "buffer" preferences only deserve one change: set the scrollback to 'unlimited'. If you ever
start compiling things from the command line, like a custom Apache install, 10,000 lines can
disappear pretty quickly.
The "display" preferences are a little more fun, as their effects can be seen instantly. See
figure 3 to get a look at this one.
Figure 3 - Display
Call me old-school, but I want a block cursor that blinks. Depending on the display I'm using,
I'll sometimes drop the point size down to 9. A quick tip for you: never turn on anti-aliasing. Not
only does it look terrible, it slows Terminal.app down - yes, even more so than it starts out. This
is one valid gripe that users of Terminal.app have. Its speed is nowhere near a real terminal, a
terminal emulator on other systems, or even a Windows DOS box (or, for that matter 'DOSbox' under OS
X. Man is that thing quick!). While things did get better in Panther, Terminal is still the
laggard, comparatively. But, hey, it looks great.
Next up are the color prefs, which go hand in hand with the display prefs. Have fun with this
one: there are no wrong answers here. Come up with a style that is easy on your eyes and makes you
feel at home. Again, I go for the old-school combo of green on black, with a pinch of ultra-modern
transparency. I have one terminal combo of light-blue on dark-blue with a rather large font. Yes,
it looks like a Commodore 64....
Stepping down brings us to the 'Window' preferences. I tend to check off just about everything
in the lower-half of the inspector window. Additionally, I like to make the terminal fairly large.
Why have text wrap if it doesn't have to?
On the last page of options, the 'keyboard' prefs allow one to alter the escape codes that are
sent to Terminal.app for each key. Unless you have a great need to change these (and you may), just
leave these at their default settings.
Now, I know you've been eyeing that large "Use Settings as Defaults" button at the bottom of the
Inspector window. Well, if you have everything set the way you like, click it! As soon as you
click it....nothing happens! Well, OK, it does save your preferences, but there is absolutely no
feedback that it done anything. For proof, quit Terminal.app and relaunch it. You should now have
a terminal that defaults to your settings. Nice, eh?
So, now we've made the terminal pretty. Great. Besides staring at a blinking cursor, now what?
Let's start with the basics. Again, you'll see where you are in the filesystem based on your
prompt, which at first should read '~'. We can start from the top to best illustrate how this
works. The very top level of the filesystem is represented by '/', or, 'the root'. Type 'cd /'
and press enter. This will 'c'hange 'd'irectory to "/". You're now at the top level of your disk
tree, basically represented by "Computer" in the Finder. You should also notice that the terminal
prompt changed from "~" to "/". Now, type "cd Users" (capitalization is important). You've moved
into the familiar Users folder. Let's see what's in here. Type "ls -l". This produces a file
'l'i's'ting of the current directory. The '-l' following the command is a switch that modifies the
behavior of the command. In this case, we want a 'l'ong list. Try an 'ls' without the '-l' switch
and you'll immediately see the difference (and, hopefully, why I prefer the long list).
So far so good, right? Nothing broke. Just remember, although the terminal brings you down to a
lower level, there's still a thin veneer between you and the OS. Not quite the movie screen the GUI
covers everything up with, but still, a level of abstraction exists. For example, when you ask for
a file listing by typing 'ls', sure, you had to do something manually. Directory information didn't
just come flying onto your screen. But neither did you have to tell the disk drive which blocks to
access. So, as always, unless you pour liquid onto your CPU, you're not going to break anything.
If you feel comfortable with these two basic exercises, the command line just may be for you!
Naturally, this doesn't scratch the surface of what can be done via the CLI. Not even the surface
of the smallest surface that exists on the surface of the CLI.
Listing files? I can do that in the Finder! Where's the power? If you're comfortable moving
from directory to directory, we can look at some more powerful commands.
Continuing with file related commands is important, as Unix treats just about everything as a
file. Your disk drive? A file. Even the terminal display can be treated as a file. We'll get
into this deeper in future columns, but safe to say, file manipulation is important.
Back in the terminal, type 'cd'. Simply typed by itself, the change directory command will bring
you back to your home directory. Now, type 'touch thefile.txt'. In short, the touch command will
either create a zero-length file, or, if the name you specify already exists, will update the date
stamp of that file to the current date and time. Get a directory listing and see if your file is
there ('ls -l', remember?).
To copy that file, you use the 'cp' command. Type 'cp thefile.txt theotherfile.txt'. 5 points
if you typed 'cp thef' and hit tab to complete. This will copy 'thefile.txt' to a file called
'theotherfile.txt'. We can alter these files as well as having copied them. There are some holy
wars in Unix-land as to the best text editor in the world. I use vi. No apologies, that's just
what I use. It will absolutely be the subject of a future column. If you know another text editor,
feel free to use it here.
Invoke vi (the 'v'isual 'e'ditor) by typing 'vi theotherfile.txt' (did you use tab completion?).
You'll be presented with a blank-ish looking screen with tildes running down the left-hand side.
Figure 4 should mirror what you're seeing.
Figure 4 - vi with an
The tildes represent a non-existent line, which, admittedly, can sometimes get confusing if
you're editing a file with tildes. I'll just give the key presses with a short description, since
I'll cover vi in a future column - case is important, by the way. Press 'i' for 'i'nsert - you're
now free to roam about the cabin. You should see a bold 'INSERT' notification at the bottom of the
edit window. Type whatever text you'd like. I just typed 'This is a test.' When you're done,
press the escape key on your keyboard. Type ":" (colon), and you should see a ":" appear at the
bottom of the window you're editing in. Follow that with 'wq' and press Enter. That tells vi to
'w'rite the file to disk and then 'q'uit. You'll be dropped back to your prompt.
I'd like to delete the original file that we created. This is done with the 'rm' command. Now,
just like files that you throw in the Trash via the Finder, be careful what you follow the 'rm'
command with. Unlike the trash, though, the files that you list will be deleted immediately. No
trash, no undo. Gone. Tab completion can be great, or you can use it without thinking after an rm
command and nuke the wrong file. Be careful out there! That said, type 'rm thefile.txt' and, after
checking yourself, press Enter. You've just deleted 'thefile.txt'.
The 'mv' (move) command moves and renames files. Renaming, after all, is just moving a file
within the same directory. Type 'mv theotherfile.txt thelastfile.txt' and press Enter.
'theotherfile.txt' just became 'thelastfile.txt'.
To bring this all home, we can open the file we created in the Finder. Switch to the finder, and
open your home directory. 10 points if you've left a Finder window of your home directory open this
whole time and watched all of these machinations take place. You should see a text file named
'thelastfile.txt' sitting there. If you double click it, it should simply launch TextEdit. Check
out our handiwork in Figure 5.
Figure 5 - TextEdit
displaying our file
While this was all a bit contrived and trivial, I'm sure you can imagine some automated routines
that compile information, save it to a file, and then display it via TextEdit or any other program.
In fact, let's try something a little more serious.
Hop back over to terminal. Fire up vi or your favorite editor. I'll give instructions for vi.
Type 'cd' so you're sure you are in your home directory. Type 'vi showdi.sh'. This will be a bash
script that will show us a report of disk information for our main disk and display it in TextEdit.
Press 'i', and you'll again see the bold 'INSERT' along the bottom of your editor window. Type the
#!/bin/bash diskutil info /dev/disk0 >
Save this file by pressing escape, typing ':wq' and pressing Enter. Type 'chmod 700 showdi.sh'
and press enter. This gives this script the ability to be executed (run) as a program (ok, this is
a bit simplified, but without this command, this script is just a text file).
Before we run this, let me note that you'll need to be an admin for this to work. When you're
ready, type "./showdi.sh" to run our script. That's dot, forward-slash, showdi.sh. Don't forget
the tab-completion for this one! Press enter. In about two seconds, TextEdit will pop up with a
short report about our disk 'disk0'. See figure 6 for what this looks like.
Figure 6 - Our
showdi.sh script in action.
Again, the details of this script and all the commands we typed will be covered in future
Apple-Fying The CLI
If you're a more seasoned user, you may have skipped some of the earlier bits of this article.
You already know your way around. You know what a hard link is and you know how to use it. You
like to fire up Terminal.app, dive in and never look back. Some things that may escape you if
you're coming from another environment:
If you're a big xterm person, there are some notable differences here. Mainly:
- Terminal.app doesn't honor switches (like "-bg") that allow you to customize the Terminal
at app launch. You have to use Terminal Inspector as described earlier.
- $TERM defaults to
"xterm-color", which is great on your own system, but can throw remote systems not ready for it.
- You can't launch a new terminal from the command line! Goofy, eh? You just have to slap
However, despair not. There are some really nice Terminal attributes. Such as:
- You can set your window title on the fly (though escape sequences and an 'echo').
- Split-screen bar (see figure 4)
- Tab completion. I couldn't survive without tab completion.
- Integration with the Services menu.
We'll step through these bits here.
If you're really into customization and want to set your window title from the command line, or
have a script that uses this functionality, you can! Try this:
echo -n -e "\033]0;Title\007"7>
The "\033" is the 'escape' key, needed to start an ANSI escape sequence. Follow this code with
the title you want, and close it out with a "\007".
You can split your terminal horizontally by clicking the 'broken square' icon in the upper
right-hand corner of the terminal window. This will display a horizontal bar that can be adjusted
to size the windows as needed. Figure 4 shows a split screen with a file listing in the upper
split, and 'top' running in the lower pane. While this functionality is useful, I use it very
little. The reason for that will be part of a future article.
Figure 7 - Terminal
with split-screen activated
Tab completion!!! All Unix veterans know some kind of completion. And when you start using it,
you'll never give it up. For you hard-core Unix people: OS X has standard tab-completion, 'nuff
said. If you don't know what this is, here's an illustration: once again, type 'cd /' to get to the
root. Now, type 'cd Li' and then press the 'tab' key. Suddenly, the line you're working on fills
itself out (to become 'cd Library/'). Now, type 'W' and a 'tab'...boom! You now have 'cd
Library/WebServer'. This cuts down on the keystrokes you need to type by a huge factor. Sometimes,
your hit 'tab' and you simply hear a beep. That's either because nothing matches, or more than one
thing matches. As an example, if you still have Classic loaded on your machine, and you type 'cd
/Sy' and press tab, you get a partial completion (to 'System') and a beep. If you press 'tab'
again, the shell will show you the matches. In this particular case, you can either accept the
match of 'System' (because it's valid), or type '\ " (backslash-space) and press 'tab' again to have
the shell complete the next match. The more you use it, the more you'll get the hang of it. Just
don't practice on Windows XP, which now supports tab completion, but has a really poor substitute of
OS X has a great feature in the Services Menu - which someone else can cover much better than I
can. Terminal.app has nice integration with this menu. Highlight some text, and then go check
Terminal->Services. There's some nice functionality there, such as: Send to mail, create new sticky
note, create new window in TextEdit, and more.
One last note for those so inclined: You should also take a look at the actual Terminal
preferences, accessed through the 'Terminal->Preferences' window. This will allow you to define
several aspects about your terminal that can help out in situations where you're trying to emulate a
different terminal. Be aware that changing the shell in the Terminal preferences screen will only
change it for shells launched through Terminal.app. Alternate terminals (see below) and ttys from
remote sessions, such as telnet or ssh, use the shell defined in your user profile. The good old
'chsh' works for this purpose, or, if you want to get all OS X about it, change the shell key in
your NetInfo record.
Well, naturally, I can't predict the future. But I can tell you that a text, command line
interface will be with us for some time to come. There are new applications showing up all the time
that are CLI only. You can find MP3 players, Gnutella clients, games, web browsers, e-mail programs
and more, that are all CLI driven. Although the Mac certainly needs it less than other platforms,
which may still be text-driven by nature, learning the CLI is of great benefit. It helps you
troubleshoot a Mac with a boot time problem, and it can help you automate your machine in better
I'd be remiss if I didn't mention that Apple's Terminal.app isn't the only terminal for OS X!
There are two more that I'm aware of. GLTerm takes the speed issue head on. All display is done
through OpenGL. It also supports X .bdf fonts. There may be cases where Terminal.app doesn't
handle some graphics issue correctly. Chances are, GLTerm will handle those cases just fine. Find
it at http://www.pollet.net/GLterm
The second terminal alternative is iTerm. iTerm shoots for features. If you spend time in KDE
or Gnome, check out iTerm. It has support for bookmarks (saving session settings), tabs, an
anti-idle function and more. You can find it at http://iterm.sourceforge.net.
This is the end...of this column only (whew!) Obviously, I'm a huge proponent of the CLI. Now,
I'm not so stubborn that I use the Terminal for everything! After all, I am a Mac user!
Anyone who read my 'Unix in OS X' article that appeared in the December MacTech should note that
I did find the solution to making an OS X 10.3.4 through 10.3.7 machine accept remote syslog
connections. In your /etc/rc file, you need to alter the syslog invocation to read:
/usr/sbin/syslogd -a 192.168.1.100/24:\* -m 0
where the IP address and mask (in CIDR notation) represent the interface to listen on.
Unfortunately, this incantation has changed a few times and the syslog binary is out of sync with
the man page. Stay tuned for any changes to remote logging!"
When he's not helping the clients of Radiotope,
you'll find Ed Marczak on the grid, fighting for the users.