The (Command) Shell Game
You can't get very far with UNIX on most systems without having a command-line interpreter. This lesson gets you up and running with a command shell quickly.
Task 13.1: What Shells Are Available?
 | If I asked a PC expert how many command interpreters are available for DOS, the immediate answer would be “one, of course.” After a few minutes of reflection, however, the answer might be expanded to include The Norton Desktop, DesqView, Windows 95, Windows 98, Windows NT, and others. This expanded answer reflects the reality that whenever there are different people using a computer, there will evolve different styles of interacting with the machine and different products to meet these needs. Similarly, the Macintosh has several command interpreters. If you decide that you don't like the standard interface, perhaps you will find that MachTen, At Ease, DiskTop, or Square One works better. |
From the very beginning, UNIX has been a programmer's operating system, designed to allow programmers to extend the system easily and gracefully. It should come as no surprise, then, that quite a few shells are available. Not only that, but any program can serve as a command shell, so you could even start right in emacs if you wanted and then use escapes to UNIX for actual commands. (Don't laugh—I've heard it's done sometimes.)
The original shell was written by Ken Thompson, back in the early UNIX's laboratory days, as part of his design of the UNIX file system. Somewhere along the way, Steven Bourne, also at AT&T, got ahold of the shell and started expanding it. By the time UNIX began to be widely distributed, sh was known as the Bourne shell. Characterized by speed and simplicity, it is the default shell for writing shell scripts, but it is rarely used as a command shell for users today.
The next shell was designed by the productive Bill Joy, author of vi. Entranced by the design and features of the C programming language, Joy decided to create a command shell that shared much of the C language structure and that would make it easier to write sophisticated shell scripts: the C shell, or csh. He also expanded the shell concept to add command aliases, command history, and job control. Command aliases allow users to rename and reconfigure commands easily. Command history ensures that users never have to enter commands a second time. Job control enables users to run multiple programs at once. The C shell is by far the most popular shell on all systems I've ever used, and it's the shell I have been using for about 20 years now, since I first logged in to a BSD UNIX system in 1980.
A command alias is a shortcut for a command, allowing you to enter a shorter string for the entire command. The command history is a mechanism by which the shell remembers commands you have typed and allows you to repeat the command without retyping the whole command. Job control is a mechanism that allows you to start, stop, and suspend commands.
In the past few years, another AT&T Labs (now Lucent) software wizard, David Korn, has built another shell on various UNIX platforms. The Korn shell, also known as ksh, is designed to be a superset of the Bourne shell, sharing its configuration files (.profile) and command syntax, but including many of the more powerful features of the C shell, too, including command aliases (albeit in a slightly different format), command history, and job control. This shell is becoming more popular, but it isn't yet widely distributed. You might not have it on your version of UNIX.
Other shells exist in special niches. A modified version of the C shell, a version that incorporates the slick history-editing features of the Korn shell, has appeared: it is called tcsh. Maintained by some engineers at Cornell University, it is 95% csh and 5% new features. The most important tcsh additions to the C shell are these:
emacs-style command-line editing
Visual perusal of the command history list
Interactive command, file, and identifying files with the first few unique characters
Spelling correction of command, file, and usernames
Automatic logout after an extended idle period
The capability to monitor logins, users, or terminals
New pre-initialized environment variables $HOST and $HOSTTYPE.
Support for a meaningful and helpful system status line
Another shell you might bump into is called the MH shell, or msh, and it's designed around the MH electronic mail program, originally designed at the Rand Corporation. In essence, the MH shell lets you have instant access to any electronic mail you might encounter. For sites that have security considerations, a restricted version of the Bourne shell is also available, called rsh (ingeniously, it's called the restricted sh shell). Persistent rumors of security problems with rsh suggest that you should double-check before you trust dubious users on your system with rsh as their login shell (the shell you use, by default, when you log in to the system).
Two other variants of the Bourne shell are worth mentioning: jsh is a version of the Bourne shell that includes C shell–style job control features, and bash, also humorously called the Bourne Again shell, is a reimplementation of the original shell with many new features and no licensing restrictions.
 | Licensing restrictions and intellectual property laws occasionally have stymied the growth of UNIX. Although UNIX is unquestionably popular with programmers, these same programmers have a burning desire to see what's inside, to learn about how UNIX works by examining UNIX itself. UNIX is owned by AT&T. Few people are able to view the source legally. Those who do look into UNIX are “tainted”: Anything they write in the future might be inspired by proprietary code of AT&T. The situation is fuzzy in many ways, and that's where the Free Software Foundation comes in. The brainchild of Richard Stallman, the FSF is slowly rewriting all the major UNIX utilities and then distributing them with the source as part of the ambitious GNU project. GNU emacs is one example; the Bourne Again shell is another; and Linux, a great free UNIX implementation, is a third. |
A quick call to awk lets us extract the default login shell of each user on the system and then use sort and uniq to collate the data. Armed with the description of all the different shells, you now can take another look:% awk -F: '{ print $7} ' /etc/passwd | sort | uniq -c 2 3361 /bin/csh 1 /bin/false 85 /bin/ksh 21 /bin/sh 11 /usr/local/bin/ksh 361 /usr/local/bin/tcsh 7 /usr/local/lib/mshYou can see that the vast majority of the people on this system use the C shell. Compute the number of entries in the password file, and then you can get a better feel for what percentage of people use which shell:
% wc -l /etc/passwd 3849
 | Many kinds of shells are available, but the most common one on sites I'm familiar with is the C shell. Clearly, the system I used for this particular set of examples has an overwhelming majority of C shell users: A combined total of 97% of the users are working within either the C shell or its descendent tcsh. |
Task 13.2: Identifying Your Shell
 | There are many different approaches to identifying which shell you're using. The easiest, however, is to type echo $SHELL or, if that fails, swoop into the /etc/passwd file to see what your account lists. It's helpful to know some alternatives because the /etc/passwd option isn't always available (some systems hide the /etc/passwd file in the interest of security). |
A much more reliable way to ascertain which shell you're using is to ask the operating system what program you're currently running. The shell variable $$ identifies the process ID of the shell. You can use $$ as a search pattern for grep on the output of ps to see what shell you are using. Here's what happens when I try it:
% ps -ef | grep $$ taylor 26905 0.0 0.2 256 144 Ai S 0:03 -csh (csh) taylor 29751 0.0 0.1 52 28 Ai S 0:00 grep 26905You can see that I'm running the C shell. Using ps in this fashion also matches the grep process (notice that the $$ have expanded to the current shell process identification, 26905). There is a leading dash on the indication of what shell I'm running because that's how the system denotes that csh is my login shell.
Another way to find out what shell I'm running is to peek into the /etc/passwd file, which you can do with some sophistication now that awk is no longer a mystery:
% awk -F: '{ if ($1 == "taylor") print "your shell is: "$7}' < /etc/passwd your shell is: /bin/cshThe best way to figure out what shell you're running, however, is to use chsh. You learn how to use chsh in the following task.
One simple technique to identify your shell is to check your prompt. If your prompt contains a %, you probably are using the C shell or modified C shell (tcsh | Once you've identified your shell, you can contemplate choosing a different one. |
Task 13.3: How to Choose a New Shell
 | In the past, the only way to switch login shells on many systems was to ask the system administrator to edit the /etc/passwd file directly. This usually meant waiting until the system administrator had time. The good news is that there's now a simple program (on almost all UNIX systems) to change login shells—it's chsh, or change shell. It has no starting flags or options, does not require that any files be specified, and can be used regardless of your location in the file system. Simply type chsh and press Return. |
The first step is to identify what shells are available for use. By convention, all shells have sh somewhere in their names, and they are located in /bin:% ls -lF /bin/*sh* -rwsr-xr-x 3 root 49152 Apr 23 1992 /bin/chsh* -rwxr-xr-x 1 root 102400 Apr 8 1991 /bin/csh* -rwxr-xr-x 1 root 139264 Jul 26 14:35 /bin/ksh* -rwxr-xr-x 1 root 28672 Oct 10 1991 /bin/sh*The chsh command enables you to change your login shell, as you will learn. The most common shells are csh, ksh, and sh.
On one of the machines I use, some shells are also stored in the /usr/local/bin directory:
% ls -lF /usr/local/bin/*sh* lrwxr-xr-x 1 root 8 Jul 26 14:46 /usr/local/bin/ksh -> /bin/ksh* -rwxr-xr-x 1 root 266240 Jan 19 1993 /usr/local/bin/tcsh*You can see that there's an entry in /usr/local/bin for the ksh shell but that it's actually just a link pointing to the file in the /bin directory.
You might find quite a few more matches to these simple ls commands. On another very different system, I tried the same two commands and found the following:
% ls -CF /bin/*sh* /bin/chsh* /bin/ksh* /bin/shelltool@ /bin/tcsh* /bin/csh* /bin/sh* /bin/shift_lines@ /bin/ypchsh* % ls -CF /usr/local/bin/*sh* /usr/local/bin/bash* /usr/local/bin/showpicture* /usr/local/bin/bash112* /usr/local/bin/sun-audio- file.csh* /usr/local/bin/ircflush@ /usr/local/bin/sun-to-mime.csh* /usr/local/bin/mush* /usr/local/bin/tcsh* /usr/local/bin/mush.old* /usr/local/bin/tcsh603* /usr/local/bin/mush725* /usr/local/bin/unshar* /usr/local/bin/ntcsh* /usr/local/bin/unship* /usr/local/bin/shar* /usr/local/bin/uupath.sh* /usr/local/bin/ship* /usr/local/bin/vsh* /usr/local/bin/showaudio* /usr/local/bin/zsh* /usr/local/bin/showexternal* /usr/local/bin/zsh210* /usr/local/bin/shownonascii* /usr/local/bin/zsh231* /usr/local/bin/showpartial*Two more shells show up here: vsh and zsh. The visual shell, vsh, is an interface much like the Norton Desktop on DOS. Watch what happens to my screen when I launch it by typing vsh:
Directory: /u1/taylor User: taylor Page 2 / 2 a .tin/ b Global.Software c Interactive.Unix d Mail/ e News/ f Src/ g bin/ h history.usenet.Z i testme _
If you have vsh on your system, you might be interested in experimenting with this very different shell.
The zsh shell is another command shell, one written by Paul Falstad of Princeton University. The Bourne Again shell, bash, also appears in the listing, as does the mush program, which is an electronic mail package.
Needless to say, many shells are available! To change my login shell to any of these alternative shells, or even just to verify what shell I'm running, I can use the change shell command:
% chsh Changing login shell for taylor. Old shell: /bin/csh New shell: _
At this point, the program shows me that I currently have /bin/csh as my login shell and asks me to specify an alternative shell. I'll try to confuse it by requesting that emacs become my login shell:
% chsh Changing login shell for taylor. Old shell: /bin/csh New shell: /usr/local/bin/gnuemacs /usr/local/bin/gnuemacs is unacceptable as a new shell.The program has some knowledge of valid shell names, and it requires you to specify one. Unfortunately, it doesn't divulge that information, so typing ? to find what's available results in the program complaining that ? is unacceptable as a new shell.
You can, however, peek into the file that chsh uses to confirm which programs are valid shells. It's called /etc/shells and it looks like this:
% cat /etc/shells /bin/ksh /bin/sh /bin/csh /usr/local/bin/ksh /usr/local/bin/tcshI'll change my shell from /bin/csh to /usr/local/bin/tcsh:
% chsh Changing login shell for taylor Old shell: /bin/csh New shell: /usr/local/bin/tcsh
Notice that, in typical UNIX style, there is no actual confirmation that anything was done. I conclude that, because I did not get any error messages, the program worked. Fortunately, I easily can check by either using chsh again or redoing the awk program with a C shell history command:
% ! awk awk -F: '{ if ($1 == "taylor") print "your shell is: "$7}' < /etc/passwd your shell is: /usr/local/bin/tcshIn the next hour, you learn more about the powerful C shell command-history mechanism.
 | Because of the overwhelming popularity of the C shell, the next few hours focus on the C shell. To get the most out of those hours, I strongly recommend that you use the C shell. |
A quick reinvocation of the chsh command changes my shell back to /bin/csh:
% chsh Changing login shell for taylor Old shell: /usr/local/bin/tcsh New shell: /bin/csh
 | If you can't change your login shell, perhaps because of not having chsh, you always can enter the C shell after you log in by typing csh. |
 | It's easy to change your login shell. You can try different ones until you find the one that best suits your style of interaction. For the most part, though, shells all have the same basic syntax and use the same commands: ls -l does the same thing in any shell. The differences, then, really come into play when you use the more sophisticated capabilities, including programming the shell (with shell scripts), customizing its features through command aliases, and saving on keystrokes by using a history mechanism. That's where the C shell has an edge, and why it's so popular. It is easy, is straightforward, and has powerful aliasing, history, and job-control capabilities, as you learn in the next hour. |
Task 13.4: Learning the Shell Environment
 | Earlier in this book, you used the env or printenv command to find out the various characteristics of your working environment. Now it's time to use this command again to look more closely at the C shell environment and define each of the variables therein. |
To start out, I enter env to list the various aspects of my working environment. Do the same on your system, and although your environment will not be identical to mine, there should be considerable similarity between the two.% env | cat -n 1 HOME=/users/taylor 2 SHELL=/bin/csh 3 TERM=vt100 4 USER=taylor 5 PATH=.:/users/taylor/bin:/bin:/usr/bin:/usr/ucb:/usr/local:/etc: /usr/etc:/usr/local/bin:/usr/unsup/bin: 6 MAIL=/usr/spool/mail/taylor 7 LOGNAME=taylor 8 EDITOR=/ucb/bin/vi 9 NAME=Dave Taylor 10 EXINIT=:set ignorecase 11 RNINIT=-hmessage -hreference -hdate-r -hsender -hsummary -hreply -hdistr -hlines -hline -hfollow -hnews -hkey -hresent -hreturn -hto -hx-original -hx-sun -hx-note -horiginator -hnntp 12 SUBJLINE=%t -- %s 13 ORGANIZATION=Educational Computing group, School of EducationThis probably seems pretty overwhelming initially. What are all these things, and why on earth should they matter? They matter because it's important for you to learn exactly how your own environment is set up so that you can change things if you desire. As you soon will be able to recognize, I have modified much of my system's environment so that the C shell does what I want it to do, rather than what its default would tell it to do.
When I log in to the system, the system defines some environment variables, indicating where my home directory is located, what shell I'm running, and so on. These variables are listed in Table 13.1.
 | I admit it: Using . as the first entry in the PATH variable is a security hazard. Why? Imagine this: A devious chap has written a program that will do bad things to my directory when I invoke that bad program. But how will he make me invoke it? The easiest way is to give the bad program the same name as a standard UNIX utility, such as ls, and leave it in a commonly accessed directory, such as /tmp. So what happens? Imagine that the . (current directory) is the first entry in my PATH, and I change directories to /tmp to check something. While I'm in /tmp, I enter ls without thinking, and voila! I've run the bad program without knowing it. Having the . at the end of the search path would avoid all this because then the default ls command is the correct version. I have it because I often do want to override the standard commands with new ones that I'm working on (an admittedly lazy practice). |
 | Having both LOGNAME and USER defined in my environment demonstrates how far UNIX has progressed since the competition and jostling between the Berkeley and AT&T versions (BSD and SVR3, respectively) of UNIX. Back when I started working with UNIX, if I was on a BSD system, the account name would be defined as LOGNAME, and if I used an SVR3 system, the account name would be defined as USER. Programs had to check for both, which was frustrating. Over time, each system has begun to use both terms (instead of using the solution that you and I might think is most obvious, which is to agree on a single word). |
A glance back at the output of the env command reveals that there are more variables in my environment than are listed in Table 13.1. That's because you can define anything you want in the environment. Certain programs can read many environment variables that customize their behavior.
Many UNIX programs allow you to enter text directly, and then they spin off into an editor, if needed. Others start your favorite editor for entering information. Both types of programs use the EDITOR environment variable to identify which editor to use. I have mine set to /usr/ucb/vi.
You learned earlier that vi can have default information stored in the .exrc file, but the program also can read configuration information from the environment variable EXINIT. To make all my pattern searches not case sensitive (meaning that a search for precision will match Precision), I set the appropriate vi variable in the EXINIT. Mine is set to :set ignorecase. If you want line numbers to show up always, you could easily have your EXINIT set to :set number.
Another program I use frequently is rn, or read Netnews. If electronic mail is the electronic equivalent of letters and magazines you receive through the postal service, Netnews is the electronic equivalent of a super bulletin board. The difference is that there are thousands of different boards, and any time a note is tacked onto any board, copies of the note shoot to other UNIX systems throughout the world. For now, you can see that I have three environment variables all defined for the rn program: RNINIT, my personal rn configuration options; SUBJLINE, indicating the format for displaying summary subject lines of new messages; and ORGANIZATION, indicating exactly what organization I'm associated with on this system. They are set as shown earlier.
 | There are many possible environment variables you can define for yourself. Most large UNIX programs have environment variables of their own, allowing you to tailor the program's behavior to your needs and preferences. UNIX itself has quite a few environment variables, too. Until you're an expert, however, I recommend that you stick with viewing these variables and ensuring that they have reasonable values, rather than changing them. Particularly focus on the set of variables defined in Table 13.1. If they're wrong, you could have trouble, whereas if other environment variables are wrong, you're probably not going to have too much trouble. |
Task 13.5: Exploring csh Configuration Files
This split between two configuration files isn't too bad, actually, because many modifications to the environment are automatically included in all subshells (a shell other than the login shell) invoked. To be specific, all environment variables are pervasive, but any C shell command aliases are lost and, therefore, must be defined in the .cshrc file to be available upon all occurrences of csh. You learn more about command aliases in the C shell in the next hour.
To begin, I use cat to list the contents of my .login file. Remember that any line beginning with a # is a comment and is ignored.% cat .login # # @(#) $Revision: 62.2 $ setenv TERM vt100 stty erase "^H" kill "^U" intr "^C" eof "^D" stty crtbs crterase # special DYNIX stuff for bs processing # shell vars set noclobber history=100 savehist=50 filec # set up some global environment variables... setenv EXINIT ":set ignorecase" # Some RN related variables... setenv RNINIT "-hmessage -hreference -hdate-r -hsender -hsummary -hreply -hdistr -hlines -hline -hfollow -hnews -hkey -hresent -hreturn -hto -hx-original -hx-sun -hx-note -horiginator -hnntp" setenv SUBJLINE "%t -- %s" setenv ORGANIZATION "Educational Computing group, School of Education" setenv NAME "Dave Taylor" newmail mesg yThis is pretty straightforward, once you remove all the comments. Three kinds of environmental configuration commands are shown: setenv, stty, and set. The setenv command defines environment variables; indeed, you can see that many of the variables shown in the previous unit are defined in my .login file.
I can use stty commands to set specific configuration options related to my terminal (stty stands for “set tty driver options”). I use this to ensure that ^h is erase (backspace), ^u is a convenient shortcut allowing me to kill an entire line, and ^c sends an interrupt to a running program. I indicate the end of a file (EOF) with ^d. The second line of the preceding output example indicates that my CRT is capable of backspacing and erasing characters on the display.
Finally, the set commands are configuration options for the C shell. I have told the C shell to warn me before it overwrites existing files with file redirection (noclobber), to remember the last 100 commands (history=100), and to remember 50 of those even if I log out and log back in (savehist=50). I also want the C shell to try, if possible, to complete filenames for me, hence the filec addition. Notice that there are two types of settings: on/off options (such as noclobber and filec), and options to which I must assign a specific numeric value (such as history and savehist).
The two commands at the end of the .login file are invoked as though I'd entered them on the command line. The newmail variable watches for new electronic mail (in the mailbox defined by the environment variable MAIL, in fact) and tells me when it arrives. The mesg y variable makes sure that I have my terminal configured so that other folks can beep me or say hello using talk, a communication tool discussed in Hour 19, “Communicating with Others.”
 | Here's more arcane UNIX nomenclature: CRT (as used in stty crtbs or cathode-ray tube) is the technology used in the screen of a standard terminal. Terminal is not accurate anymore, however, because the command stty crtbs also works on my LCD (liquid-crystal diode, if you must know) laptop. |
How about the other file—the one that's read by the C shell each time a shell is started?
% cat .cshrc # # Default user .cshrc file (/bin/csh initialization). set path=(. ~/bin /bin /usr/bin /usr/ucb /usr/local /etc /usr/etc /usr/local/bin /usr/unsup/bin / # Define a bunch of C shell aliases alias diff '/usr/bin/diff -c -w' alias env 'printenv' alias from 'frm -n' alias info ssinfo alias ll 'ls -l' alias ls '/bin/ls -F' alias mail Mail alias mailq '/usr/lib/sendmail -bp' alias newaliases 'echo you mean newalias...' alias rd 'readmsg $ | page' alias rn '/usr/local/bin/rn -d$HOME -L -M -m -e -S -/' alias ssinfo 'echo "connecting..." ; rlogin oasis' # and some special stuff if we're in an interactive shell if ( $?prompt ) then # shell is interactive. alias cd 'chdir !* ; setprompt' alias setprompt 'set prompt="$system ($cwd:t) ! : "' set noclobber history=100 system=mentor filec umask 007 setprompt endifAgain, any line that begins with a # is considered a comment. There are, therefore, two primary types of commands in this script: the C shell environment modification (set) and the command alias (alias). The first defines the PATH I want to use, although in a format slightly different from the colon-separated listed shown by env. The csh command always ensures that the environment variable and shell variable match, and so, although I opt to change the path here as a set, I could just as easily use setenv PATH.
You learn all about aliases in the next hour, but for now you should know that the format is alias word command (or commands) to execute. When I enter ls, for example, you can see that the shell has that aliased to /bin/ls -F, which saves me from having to type the -F flag each time.
The C shell also has conditional statements and various other commands to indicate what commands to run. Here I'm using if (expression) then to define a set of commands that should be used only when the shell is interactive (that is, I'm going to be able to enter commands). An example of a noninteractive shell is the shell vi uses to create a listing when I enter !!ls within the editor. The $?prompt variable is true if there is a prompt defined for the shell (that is, if it's interactive). If not, the variable is false, and the shell zips to the endif before resuming execution of the commands.
If it is an interactive shell, however, I create a few further aliases and again define some C shell configuration options, to ensure that the options are always set in subshells. The umask value is set, and I then invoke setprompt, which is a command alias that runs the command set prompt="$system ($cwd:t) ! : ".
 | If you're thinking that there are various ways to configure the shell, you are correct. You can have an incredibly diverse set of commands in both your .login and your .cshrc files, enabling you to customize many aspects of the C shell and the UNIX environment. If you use either the Bourne shell or the Korn shell, the configuration information is kept in a similar file called .profile. |