Using the shell (Terminal) in Mac OS X
Many Mac OS X users will not have any need to use the Unix shell that underlies their graphical interface. They are missing out.
This article was first written in late 2002. Since then, more than
a few things have changed.
For one thing, Apple apparently saw the light and stopped
using tcsh as their default shell, so if you've bought a newer
Mac, your Terminal will use Bash automatically.
They've also moved to Intel chips. I bought a
and sold the iBook to someone on eBay. The use of Intel chips
allows virtualization of x86 operating systems through products
Workstation. That lets me run Linux and Windows as guest OSes. You
can do that with the Motorola chips too, but it requires emulation, which makes it much slower.
There are some disquieting aspects to the Intel change. As
I write this, Apple is yet to release kernel source for the
Intel version (Mac OS X uses a Darwin core that has been open source until now). While they have yet to say that they are NOT
going to release it, the suspicion is that they are holding back
from fear of clones on ordinary Intel hardware. That could
be very dangerous to Apple's sales, but the threat may not be
as great as it might seem: Apple controls the hardware very
tightly and their OS code can be strongly slanted toward
Apple designs. There are also large parts of Mac OS X that cannot
be legally copied. It might even be good for Apple if there were
Intel clones running an inferior rake-off based on Darwin code.
There have been many other changes too, including more work in
the way daemons are started and controlled.
And we can't forget all the patches and bug fixes. Particularly
we need to remember that although we as Mac users have less to fear
from viri and malware, we are not immune, and as Macs become more
popular the danger increases. We'll likely never reach the
level that Windows has (and Windows itself should be less
Vista), but complacent over confidence is dangerous.
Macs seem to be becoming more popular with the tech crowd. I
have noticed more than a few folks using Mac laptops at trade shows
and technical seminars. Now and then I ride the train to Boston
and I've sat next to people using Macs more than once.
The presence of Unix underneath is certainly attractive for
folks who want it. I think in some ways it's more interesting
to the older Unix types.. the pace of change in Linux is sometimes
too much for us, and the cavalier changes to commands can be
upsetting. I like Linux, but the BSD base of Mac OS X is like
comfortable old shoes.
This was the first Mac OS X article I wrote, but you'll find a good number of other Mac related articles here now.
By the way, if you are completely unfamilar with Unix command line interfaces, you
can get a very complete and basic introduction from Take Control of the Mac Command Line with Terminal. That's an
inexpensive PDF book that starts by assuming no knowledge whatsoever. It explains everything you need
to know to make use of OS X Terminal.
Why use Terminal (the shell) at all?
Many Mac OS X users won't have any need to use the Unix shell
that underlies their graphical interface. Some will likely disdain
the very idea, but for those adventurous enough to try it, a whole
new world awaits.
The shell is accessed through the Terminal program, which you
will find under Applications->Utilities. Fire it up and you'll
be presented with this:
This section only applies to older versions of Mac OS X.
The obsessively observant will notice that this shell is a
"tcsh" session, which means you would be using tcsh as your shell.
The very first thing I would do is go to Terminal Preferences and
change it to use /bin/bash instead (current Mac OS X defaults to /bin/bash so this is unnecessary):
There's a very good reason for that. The tcsh shell is actually
a pretty good shell, but its ancestry is bad. It comes from the
csh, which is a simply horrible scripting shell (see http://www.faqs.org/faqs/unix-faq/shell/csh-whynot/
if you are more than mildly interested in why I say that). The
history behind this is that csh was designed not as a scripting
language, but as something that was easy for users. The "other"
shell (/bin/sh) had good scripting and redirection power, but
wasn't particularly friendly to users.
Over time, other shells came along that made the unfriendly
/bin/sh more user friendly. The two that gained the most following
are ksh and bash. Simple scripts in either shell will work in
/bin/sh, and all but the most complicated ksh or bash scripts will
work in either shell. There's no compatability with tcsh
Here's the thing: Mac OS X has a beautiful graphical user
interface. There is no reason for you to be using the shell at all
EXCEPT for its power for scripting and accessing the underpinnings
of Unix. Most GOOD shell scripts you come across on the web or
magazines will be sh, bash or ksh. So why not start out learning
the kind of things that will really be useful? If bash were any
more difficult or less friendly than tcsh, using that might make
sense, but bash is every bit as easy and friendly, and some would
say it is even more friendly.
Understand that I'm not saying that someone who is already
comfortable with csh or tcsh should dump it and use bash. Those
people should continue to use what they are comfortable with. This
is directed at those of you who have no previous experience: don't
waste your time with tcsh.
You'll also want to do:
chsh -s /bin/bash
and unfortunately there's even more to do to get rid of tcsh
entirely. Following the directions I gave here leaves you running
bash, but it has SHELL still pointing at /bin/tcsh. To fix that,
you need to explicitly set SHELL in your .bashrc file. What you
want is a .bash_profile like this:
and .bashrc like this:
alias l="ls -l"
Of course the PATH and aliases are my preferences.
That's the way I did it, but there is another way if you are an
administrator. In Applications/Utilities you will find NetInfo
Manager. Fire that up, and if the domain "/" isn't already open,
choose "Open" and once "/" is open, click the little lock at the
bottom left of the panel. You'll be asked for your password, and
then are allowed to make changes. Drill into Users, find your
account, and then double click "shell" and change it to
Netinfo is gone as of Leopard (October 2007). Good riddance.
Slashes: forward or back?
Although people get this wrong often, this "/" is a slash and this "\" is a backslash. A "/" is also known as a virgule; a "\" is sometimes called a reverse solidus. Look those up in Wikipedia if you want to know more.
Unixish systems use slashes to separate file paths: it's /usr/lib/whatever. Backslashes are only used to quote special characters. For example, single quotes are usually found in pairs, and have special meaning. So if I want to use one without that meaning, I need to quote it:
I can't cd/usr/my directory
Ahh, spaces. Here's the best thing to remember: spaces have to separate commands and their arguments. "cd/usr" will not work; "cd /usr" will. You can put in as many spaces as you like between the "cd" and the " /usr" , but you must have at least one.
If your filename or path has spaces, you must quote or escape them:
cd "/usr/my directory" (NOT "cd /usr/my directory" !)
cd /usr/my\ directory
How do I create a BAT file (shell script)?
Put your commands in a file of ANY name and make it executable. That might look like
chmod 755 myscript
(though you do need to learn much more about Unixish permissions).
Why doesn't "ls *.*" work?
Because Unixish wildcards are literal. That *.* means any file with a "." in it. It won't show files that don't contain periods.
Unixish wildcards are also much more powerful than you will first realize. You will want to learn more about how they work later.
Where's my A:? Where's my D:?
Unixish systems don't do additional drives this way. Instead, drives and DVDs and even USB sticks get attached (mounted) to the filesystem. It's important to know that it does not matter where: you could attach a drive at /usr/mydrive or at /tmp/foo.
Mac OS X does this a bit differently, normally putting things under /Volume, though you can persuade it to put things elsewhere.
Things aren't quite what they seem
Obviously this isn't traditional Unix. If Netinfo is what it
really takes to change my shell, then /etc/passwd isn't being used
for that. If I examine the /etc/passwd file I can see my account
there, but that's NOT the account used for logging in at the
console. Even more strange is that I can "su" to accounts that are
NOT in /etc/passwd (but are console login accounts). There's more
going on here than meets the eye: some of the function of
traditional Unix files is handled by Netinfo instead.
Not your typical Unix shell
Mac OS X has made some changes that old Unix folk may find a
little disconcerting. First, logging out doesn't close the shell
window (you can change that in Window Settings). More unusual (for
Unix folk) is that case doesn't always matter. I can:
and I'll be in "appl". That's not true for wild cards though: I
This is very confusing for old Unix hands. After making "appl",
I cannnot "mkdir Appl". This can also cause problems with files
brought from other Unix systems - although it is a little unusual,
it is not unheard of to have two very different files whose names
only differ in capitalization. Keep that in mind.
See HFS+ File System for more on that.
You are also allowed to do such awful things as
Of course you had better understand that Vi isn't going to put
up with this "case doesn't matter" nonsense.
Mac file structure
The integration of Mac files to Unix is not entirely seamless.
One difference is that Mac considers a text file to have only
Carriage Returns (CR) as line endings. Windows and Dos use Carriage
Return and Linefeed (CRLF) and Unix uses only Line Feeds (LF). So
if you save a file as text from most Mac applications, it gets
saved with CR line endings. Unix programs (yes, even Mac OS X Unix
programs) expect LF endings. If you will be using Unix text editors
(and you will), you will need to convert the files. That's not
hard, but we'll get to it later. Keep this in mind if you are
learning shell scripting and thought that it would be nice to use,
say, AppleWorks to create the scripts. That just won't work.
Finally, Unix has no concept of the Data and Resource forks that
Mac applications use. So while ordinary Unix usage would be to copy
a file like this:
cp file newfile
that won't work with applications. Mac OS X provides Unix
"Cpmac" and "Mvmac" commands to remedy that.
But it is still Unix, right?
Yes, it is. You can pick up a lot of knowledge just be reading
about other Unix systems. Mac OS X is based on BSD Unix, but a lot
of articles about Linux or general Unix will be applicable. As I
mentioned earlier, most shell scripts will be bash compatible, and
of course any book on Bash will be
You can even discard all the graphical niceties if you like.
Yes, there is a simple white on black vt100 screen in there if you
want it. One way to get it is to either enable the root account
(NetInfo Manager, Security, Enable Root User). That creates an
"Other" login box that you can choose and either type "root" into
or ">console". There's no password for >console, but then you
have to log in again (as yourself or root) at the vt100 screen.
Logout to return to the normal graphical login screen.
Another way to get there is do do a "sudo shutdown now", which
looks like it's bringing you to single user mode. You can also get
to that by holding the Apple Key and "S" during startup. The only
way out of there is reboot: this is BSD Unix, not System V with
Something else useful
There are several things that your machine should do
periodically. If you left your machine up and running (and didn't
let it go to sleep), it would do these things itself, but they are
scheduled for odd times of day by default. You can have it do this
work yourself by running:
("sudo" will ask for a password - that's YOUR password it wants.
See Sudo for more information)
Run these daily, weekly, and monthly just as their names imply.
In another article I'll cover what they do and show you more ways
to have them run automatically, but this will work for now.
Recent OS X versions no longer use cron - see Ding Dong, the Cron is dead. and these daily/weekly/monthly files are not present.
I'll close with the "vi" command to convert Mac files to Unix (I
have more on "vi" at Vi
Primer). "vi" is another of those Unixy things that most folks
hate, but die hard Unix folks couldn't live without. Understand
ahead of time that vi is not supposed to be friendly. It is
supposed to be fast and powerful. The comparison is your Ford SUV
vs. a competition rail dragster. You probably wouldn't want to use
the dragster to go to the supermarket, but if you had to cover a
quarter mile as fast as possible that would be your choice.
Likewise, vi probably will not be your favorite word processor
(though it is mine). But vi and its cousins will be indispensable
when you need to make complex, automatic edits to text files.
Anyway, here's what you do to "fix" Mac text files in vi:
Hit ":". The cursor drops to the bottom of the screen. Type
"1,$s/" and then press CTRL-V followed by CTRL-M. When you press
CTRL-V nothing appears to happen, but the CTRL-M shows up as "^M".
Continue with "/" and then CTRL-V again. Hit RETURN (which will
show up as ^M and you could do that too - I just like it this way)
and finally "/g". On your screen the whole thing looks like:
What does that mean? It means "Starting at line 1 and stopping
at the end of the file (1,$), substitute (s) any CTRL-M (/^M/) with
Unix CTRL-M (^M/) and do it for the entire line rather than just
the first CTRL-M you find (g) (On most other Unixes I'd just do
s/^M//g ; I don't know why Mac OS X didn't let me do that). It is a
little strange that you replace ^M with ^M but get something
entirely different, but that's a subject for another day. The
morbidly curious can start by typing "man stty" if they need to
Several people have written to point out that %s is equivalent
to 1,$. That's true, but I never use it because I just prefer being
Now ":wq" to write it out and the file now has Unix style line
Of course you don't need vi if you would rather put this in
cat file1 | tr "\\r" "\\n" > file2
will also convert line endings.
You may also need to be concerned about UTF-16 conversions.
Want more? You
can get a very complete and basic introduction to the OS X command line from Take Control of the Mac Command Line with Terminal, an
inexpensive PDF book that starts by assuming no knowledge whatsoever. It explains everything you need
to know to make more use of OS X Terminal.
Another excellent book is Linux Phrasebook (yes, that's Linux but many of the shell commands are identical or very, very similar.
I hope these tips will get you started using the shell in Mac OS X terminal.
If this page was useful to you, please help others find it:
More Articles by Tony Lawrence
- Find me on Google+
Have you tried Searching this site?
Unix/Linux/Mac OS X support by phone, email or on-site:
This is a Unix/Linux resource website. It contains technical articles about Unix, Linux and general computing related subjects, opinion, news, help files, how-to's, tutorials and more. We appreciate comments and article submissions.
Publishing your articles here
Jump to Comments
Many of the products and books I review are things I purchased for my own use. Some were given to me specifically for the purpose of reviewing them. I resell or can earn commissions from the sale of some of these items. Links within these pages may be affiliate links that pay me for referring you to them. That's mostly insignificant amounts of money; whenever it is not I have made my relationship plain. I also may own stock in companies mentioned here. If you have any question, please do feel free to contact me.
Specific links that take you to pages that allow you to purchase the item I reviewed are very likely to pay me a commission. Many of the books I review were given to me by the publishers specifically for the purpose of writing a review. These gifts and referral fees do not affect my opinions; I often give bad reviews anyway.
We use Google third-party advertising companies to serve ads when you visit our website. These companies may use information (not including your name, address, email address, or telephone number) about your visits to this and other websites in order to provide advertisements about goods and services of interest to you. If you would like more information about this practice and to know your choices about not having this information used by these companies, click here.