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:
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:
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.
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 ny 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.
You are also allowed to do such awful things as
VI MYFILE
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 seemless. 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 shotdown 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.
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:
:1,$s/^M/^M/g
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.
Originally appeared at http://www.aplawrence.com/MacOSX/macosxshell.html
Please read this disclaimer
Copyright and Reprint Info
A.P. Lawrence provides SCO Unix and Linux consulting services http://www.pcunix.com
