Using the shell (Terminal) in Mac OS X
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 MacBook Pro, and sold the iBook to someone on eBay. The use of Intel chips allows virtualization of x86 operating systems through products like Parallels 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 vulnerable with 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 though.
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:
. ~/.bashrc ENV=$HOME/.bashrc export ENV
and .bashrc like this:
PATH=$PATH:$HOME/bin:/usr/local/bin alias lc=ls alias l="ls -l" SHELL=/bin/bash
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 /bin/bash.
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:
mkdir appl cd Appl
and I'll be in "appl". That's not true for wild cards though: I cannot
mkdir appl cd Ap*
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 very useful.
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 init states.
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 /etc/daily sudo /etc/weekly sudo /etc/monthly
("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 know now.
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 specific.
Now ":wq" to write it out and the file now has Unix style line endings.
Of course you don't need vi if you would rather put this in another file:
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.
(OLDER) <- More Stuff -> (NEWER) (NEWEST)
Printer Friendly Version