MCA 309

Getting Started
1.1 Working in the UNIX Environment
Before you can start using UNIX, your system administrator has to set up a UNIX account for you. Think of this account as your office - it's your place in the UNIX environment. Other users may also be at work on the same system. At many sites, there will be a whole network of UNIX computers. So in addition to knowing your account name, you may also need to know the hostname (name) of the computer that has your account.
Each user communicates with the computer from a terminal or a window. To get into the UNIX environment, you first connect to the UNIX computer. (You may have a terminal that's already connected to the computer.) Next, you start a session by logging in to your UNIX account. Logging in does two things: it identifies which user is in a session, and it tells the computer that you're ready to start working. When you've finished working, you log out - and, if necessary, disconnect from the UNIX computer.
1.1.1 Connecting to the UNIX Computer
If you turn on your terminal and see a message from the UNIX computer that looks something like this:login:
you can probably skip ahead to the section "Logging In" later in this chapter. Otherwise, browse through the next few sections and find the one that applies to you. (We can't cover every user's situation exactly. If none of these suggestions helps you enough, ask another UNIX user or your system administrator.)
1.1.1.1 Connecting from another operating system
If you're using a personal computer to connect to the UNIX system, you'll probably need to start a terminal emulation program. Some common programs are procomm, qmodem, kermit, minicom, and telnet. (There are lots of others.)
If you start the program and get a UNIX "login:" prompt, you're ready to log in. But if your screen stays blank or you get another message that you don't understand, check with another user or your system administrator for help.
1.1.1.2 Connecting with a data switch
Your office may have a data switch, a port contender, or another system that allows you to select which computer you will connect to. Like a telephone switchboard, this connects your terminal to one of a number of computers. Enter your computer's hostname or code number at the prompt - or choose from the menu of hosts.
1.1.2 Logging In
The process of making yourself known to the UNIX computer system and getting to your UNIX account is called logging in. Before you can start work, you must connect your terminal or window to the UNIX computer (see the previous sections). Then log in to UNIX and identify yourself. To log in, enter your username (usually your name or initials) and a private password. The password does not appear on the screen as you enter it.
When you log in successfully, you will get some system messages and finally the UNIX shell prompt (where you can enter UNIX commands). A successful login to the system named nutshell would look something like this:O'Reilly & Associates, Inc.nutshell.oreilly.com: Solaris UNIX version 2.5 login: johnPassword:Last login: Mon Nov 3 14:34:51 EST 1997 from joe_pc ------------- NOTICE TO ALL USERS -----------------The hosts nutshell, mongo and cruncher will be downfor maintenance from 6 to 9 PM tonight.--------------------------------------------------- My opinions may have changed, but not the fact that I am right.Tue Nov 4 12:24:48 EST 1997%
In this example, the system messages include a "fortune" and the date. Although this example doesn't show it, you may be asked for your terminal type, accounting or chargeback information, and so on. The last line to appear is the UNIX shell prompt. When you reach this point, you're logged in to your account and can start using UNIX commands.
Instead of a shell prompt, you may get a menu of choices ("email," "news," and so on). If one of the choices is something like "shell prompt" or "command prompt," select it. Then you'll be able to follow the descriptions and examples in this book.
The messages that appear when you log in differ from system to system and day to day. The shell prompt also differs. The examples in this book use the percentage sign as a prompt (%).
Let's summarize logging in, step by step:
1. If needed, connect your terminal or window to the UNIX system.
2. If you don't have a "login:" prompt, press the [RETURN] key a few times until you see that prompt on the screen.
3. Type in your username in lowercase letters at the prompt. For example, if your login name is "john," type:login: john
Press the [RETURN] key.
The system should prompt you to enter your password. If passwords aren't used on your system, you can skip the next step.
4. If you were assigned a password, type it at the prompt. For security, your password is not displayed as you type it:Password:
Press the [RETURN] key after you finish typing your password.
The system verifies your account name and password, and, if they're correct, logs you in to your account.
1.1.2.1 Problem checklist
Nothing seemed to happen after I logged in.
Wait a minute, since the system may just be slow. If you still don't get anything, ask other users if they're having the same problem.
The system says "login incorrect".
Try logging in again, taking care to enter the correct name and password. Be sure to type your username at the "login:" prompt and your password at the "password:" prompt. Backspacing may not work while entering either of these; if you make a mistake, use [RETURN] to get a new "login:" prompt and try again. Also make sure to use the exact combination of upper- and lowercase letters your password contains.
If you still fail after trying to log in a few more times, check with your system administrator to make sure you're using the right username and password for your account.
All letters are in UPPERCASE and/or have backslashes (\) before them.
You probably entered your username in uppercase letters. Type exit and log in again.
1.1.3 Remote Logins
The computer you log in to may not be the computer you need to use. For instance, you might have a workstation on your desk but need to do some work on the main computer in another building. Or you might be a professor doing research with a computer at another university.
Your UNIX system can probably connect to another computer to let you work as if you were sitting at the other computer. To do this, you first log in to your local computer. Then you start a program on your local computer that connects to the remote computer. Some typical programs are telnet and rlogin (for connecting over a computer network) as well as cu and tip (for connecting through telephone lines using a modem). You use the remote system until you're done; when you log off the remote computer, the remote-login program quits, and then returns you to your local computer.
The syntax for most remote-login programs is:
program-name remote-hostname
For example, if Dr. Nelson wanted to connect to the remote computer named biolab.medu.edu, she'd log in to her local computer (named fuzzy) first. Next, she'd use the telnet program to reach the remote computer. Her session might look something like this:login: jenniferPassword: NOTICE to all second-floor MDs: meeting in room 304 at 4 PM. fuzzy% telnet biolab.medu.edu Medical University Biology Laboratory biolab.medu.edu login: jdnelsonPassword: biolab% . . .biolab% exitConnection closed by foreign host.fuzzy%
Her accounts have shell prompts that include the hostname. This reminds her when she's logged in remotely. If you use more than one system but don't have the hostname in your prompt.
1.1.4 The UNIX Shell
Once you've logged in, you're working with a program called a shell. The shell interprets the commands you enter, runs the program you've asked for, and generally coordinates what happens between you and the UNIX operating system. Common shells include Bourne (sh), Korn (ksh), and C (csh) shells, as well as bash and tcsh.
For a beginner, the differences between most shells are slight. If you plan to do a lot of work with UNIX, though, ask your system administrator which shell your account uses; you should learn more about your shell and its set of special commands.
1.1.5 The Shell Prompt
When the system finishes running a command, the shell replies with a prompt to tell you that you can enter another command line.
Shell prompts usually contain $ or %. The prompt can be customized, though, so your own shell prompt may be different.
1.1.6 Entering a Command Line
Entering a command line at the shell prompt tells the computer what to do. Each command line includes the name of a UNIX program. When you press [RETURN], the shell interprets your command line and executes the program.
The first word that you type at a shell prompt is always a UNIX command (program name). Like most things in UNIX, command names are case-sensitive; if the command name is lowercase (and most are), you must type it in lowercase. Some simple command lines have just one word: the command name.
1.1.6.1 date
An example single-word command line is date. Entering the command date displays the current date and time:% dateTue Nov 4 13:39:24 EST 1997%
As you type a command line, the system simply collects your input from the keyboard. Pressing the [RETURN] key tells the shell that you have finished entering text and that it can start executing the command.
1.1.6.2 who
Another simple command is who. It lists each logged-on user's username, terminal number, and login time.
The who command can also tell you who is logged in at the terminal you're using. The command line is who am i. This command line consists of the command (who) and arguments (am i). (The section "Syntax of UNIX Command Lines," later in this chapter, explains arguments.)% who am icactus!john tty23 Nov 6 08:26 (rose)
The response shown in this example says that:
· "I am" John.
· I'm logged on to the computer named "cactus."
· I'm using terminal 23.
· I logged in at 8:26 on the morning of November 6.
· I started my login from another computer named "rose."
Not all versions of who am i give the same information.
1.1.7 Correcting a Mistake
What if you make a mistake in a command line? Suppose you typed dare instead of date and pressed the [RETURN] key before you realized your mistake. The shell will give you an error message:% daredare: command not found%
Don't be too concerned about getting error messages. Sometimes you'll get an error even if it appears that you typed the command correctly. This can be caused by typing control characters that are invisible on the screen. Once the prompt returns, reenter your command.
Most modern shells let you recall previous commands and edit command lines. If you'll be doing a lot of work at the shell prompt, it's worth learning these handy techniques. They take more time to learn than we can spend here, though. Ask other users for help or read a reference book for your shell. We'll concentrate on simple methods that work with all shells.
If you see a mistake before you press [RETURN], you can use the [BACKSPACE] key to erase the mistake and put in the correction.
The erase character differs from system to system and from account to account, and can be customized. The most common erase characters are:
· [BACKSPACE]
· [DELETE], [DEL], or [RUBOUT] key
· [CTRL-H]
[CTRL-H] is called a control character. To type a control character (for example, [CTRL-H], hold down the [CTRL] key while pressing the letter "h". (This is like the way you make an uppercase letter: hold the [SHIFT] key while pressing a letter key.) In the text, we will write control characters as [CTRL-H], but in the examples, we will use the standard notation: ^H. This is not the same as pressing the ^ (caret) key, letting go, and then typing an H!
The key labeled [DEL] may be used as the interrupt character instead of the erase character. (It's labeled [DELETE] or [RUBOUT] on some terminals.) This key is used to interrupt or cancel a command, and can be used in many (but not all) cases when you want to quit what you're doing. Another character often programmed to do the same thing is [CTRL-C].
Some other common control characters are:
[CTRL-U]
Erases the whole input line; you can start over.
[CTRL-S]
Pauses output from a program that is writing to the screen.
[CTRL-Q]
Restarts output after a pause by [CTRL-S].
[CTRL-D]
Used to signal end-of-input for some programs and return you to a shell prompt. If you type [CTRL-D] at a shell prompt, it may also log you out of the UNIX system.
Find the erase and interrupt characters for your account and write them down:
_______ Backspace and erase a character
_______ Interrupt a command
1.1.8 Logging Out
To end a UNIX session, you must log out. You should not end a session by just turning off your terminal! To log out, enter the command exit. (In many cases, the command logout will also work.) Depending on your shell, you may also be able to log out by typing [CTRL-D].
What happens next depends on the place from which you've logged in:
· If your terminal is connected directly to the computer, the "login:" prompt should appear on the screen.
· If you're using a window system, the window will probably close. If you have additional windows open, you'll need to log out or close them, too. You may also need to terminate the window system itself.
· If you were connected to a remote computer, the system prompt from your local computer should reappear on your screen. (That is, you're still logged in to your local computer.) Repeat the process if you want to log out from the local computer.
6.1 What Environment Variables Are Good For
Many UNIX utilities, including the shell, need information about you and what you're doing in order to do a reasonable job.
What kinds of information? Well, to start with, a lot of programs (particularly editors) need to know what kind of terminal you're using. The shell needs to know where any commands you want to use are likely to be found. Lots of UNIX programs (like mail programs) include a command to start an editor as a subprocess; they like to know your favorite editor. And so on.
Of course, one could always write programs that made you put all this information on the command line. For example, you might have to type commands like:% mail -editor vi -term aardvark48 -favoritecolor blue_no_red
But your favorite editor probably doesn't change every day. (Nor will your favorite color.) The terminal you use may change frequently, but it certainly won't change from the time you log in until the time you log out. And you certainly wouldn't want to type something like this whenever you want to send mail.
Rather than forcing you to type this information with every command, UNIX uses environment variables to store information that you'd rather not worry about. For example, the TERM (5.10) environment variable tells programs what kind of terminal you're using. Any programs that care about your terminal type know (or ought to know) that they can read this variable, find out your terminal type, and act accordingly.
Similarly, the directories that store the commands you want to execute are listed in the PATH (6.4) variable. When you type a command, your shell looks through each directory in your PATH variable to find that command. Presumably, UNIX wouldn't need a PATH variable if all commands were located in the same directory; but you'll soon be writing your own commands (if you aren't already), and storing them in your own "private" command directories (4.2), and you'll need to tell the shell how to find them (8.7).
Warning!
Environment variables are managed by your shell. The difference between environment variables and regular shell variables (6.8) is that a shell variable is local to a particular instance of the shell (such as a shell script), while environment variables are "inherited" by any program you start, including another shell (38.4). That is, the new process gets its own copy of these variables, which it can read, modify, and pass on in turn to its own children. In fact, every UNIX process (not just the shell) passes its environment variables to its child processes.
You can set environment variables with a command like this:
;
% setenv NAME value C shell$ NAME=value; export NAME Bourne or Korn shell
There's nothing particularly special about the NAME; you can create environment variables with any names you want. Of course, these don't necessarily do anything for you; variables like PATH and TERM are important because lots of programs have "agreed" (6.3) that these names are important. But if you want to create an environment variable that holds the name of your lover, that's your business:% setenv LOVER Judy
If you're so inclined, you could write a program called valentine that reads the LOVER environment variable and generates an appropriate message. If you like short-term relationships or tend to forget names, this might even be convenient!
By convention, the names of environment variables use all uppercase letters. There's nothing to enforce this convention - if you're making your own names, you can use any capitalization you please. But there's no advantage to violating the convention, either. The environment variables that are used by standard UNIX programs all have uppercase names. [I usually make my shell variable names lowercase so it's easy to tell the difference. -JP ]
If you want the C shell to forget that an environment variable ever existed, use the command unsetenv NAME. (Some Bourne shells, but not all, have a similar command: unset NAME.)
printenvenv
If you want to list all of your environment variables, use printenv or env. (Both are on the CD-ROM.) The printenv command also lets you ask about a particular variable. Here's a typical report:% printenv EDITOREDITOR=/usr/local/bin/emacs% printenvHOME=/home/los/mikelSHELL=/bin/cshTERM=sunUSER=mikel PATH=/usr/local/bin:/usr/ucb:/bin:/usr/bin:.:/home/los/mikel/binLOGNAME=mikel PWD=/home/los/mikel/power/articlesPRINTER=psEDITOR=/usr/local/bin/emacs
The set (6.8) command provides a similar listing of shell variables.
You can also use the echo (8.6) command to show the value of a particular variable, preceding the variable name with a dollar sign (which tells the shell to substitute the value of the variable):% echo $TERMxterm


6.3 Predefined Environment Variables
We've said that environment variables are used to store information that you'd rather not worry about, and that there are a number of standard environment variables that many UNIX programs use. These are often called "predefined" environment variables - not because their values are predefined, but because their names and uses are predefined. Here are the most important ones:
· PATH (6.4) contains your command search path (8.7). This is a list of directories in which the shell looks to find commands. It's usually set in one of your shell setup files (2.2).
· EDITOR can be loaded with the name of your favorite editor. It's usually set in one of your shell setup files. Some programs distinguish between EDITOR (usually set to a line editor (33.1) such as ed) and VISUAL (set to a full-screen editor like vi). Many people don't follow that convention; they set both to the same editor. (The Korn shell checks VISUAL and EDITOR, in that order, to determine your command editing mode (11.13).)
· PRINTER (43.4) can be loaded with the name of your default printer. It's quite useful at a site with many printers - you don't need to tell lpr (43.2) which printer to use. This variable is usually set in one of your shell setup files.
· PWD contains the absolute pathname of your current directory. It's set automatically by the cd command in some UNIX shells. PWD may be fooled (14.13) by cding through symbolic links.
· HOME (14.11) (called LOGDIR on some systems) contains the absolute pathname of your home directory. It's set automatically when you log in.
· SHELL contains the absolute pathname of your login shell. It's set automatically whenever you log in.
· USER or LOGNAME contains your username. It's set automatically when you log in, and doesn't change.
· TERM (5.10) contains the name of your terminal type in the termcap or terminfo database. It's usually set in a shell setup file.
· TERMCAP (5.4) can be loaded with the complete termcap database entry for the terminal you are using. This may make some programs start up more quickly, but it's not necessary. It's set (under some conditions) by the tset command, which is usually run in your shell setup file.
· ENV contains the name of an initialization file to be executed whenever a new Korn shell is started. (See article 2.2.) Korn shell only.
· PAGER can be set to the name of your favorite page-by-page screen display program like more (25.3) or less (25.4). (Programs like man (50.1) use PAGER to determine which paging program to use if their output is longer than a single screen.)
· EXINIT (30.35, 6.10) stores setup options for the vi editor (and the ex editor, where EXINIT got its name).
· PS1 contains the primary prompt (i.e., interactive command prompt) for Bourne shells. (The C shell doesn't store the prompt in an environment variable. It uses a shell variable called prompt because the .cshrc file (2.2) is read to set up each instance of the shell. See article 7.2.)
· PS2 (9.13) contains the secondary prompt (used within compound commands like while and for) for Bourne shells.
· MANPATH (50.10), if your man (50.1) command supports it, is a colon-separated list of directories to search for manual pages.
· TZ (6.6) contains the time zone. This is a name of a file in /usr/lib/zoneinfo that provides time zone information for your locality. It is read by commands like date (51.10, 6.7).
· DISPLAY is used by the X Window System (1.31) to identify the display server (keyboard and screen handling program) that will be used for input and output by X applications.
Because Bourne-type shells don't make as strict a distinction between environment variables and shell variables as the C shell does, we've included a few things here that might not be on other people's lists.
We may have implied that environment variables are relatively constant (like your favorite editor). That's not true. For example, in a windowing environment, the current length of your window might be kept in an environment variable. That can change as often as you resize your window. What is true (fortunately) is exactly what we've said: environment variables store information that you'd rather not have to worry about.
6.4 The PATH Environment Variable
Of all the environment variables, the PATH and TERM (5.10) variables are the most important. The others are often great conveniences; but PATH and TERM can make your life miserable if they get screwed up.
The PATH variable is just a list of directories separated by colon (:) characters. The shell searches through these directories in order whenever it needs to find a command. So, if you want to execute commands in /bin, /usr/bin, /usr/local, the current directory, and your personal bin directory, you would put a line like the one below in your .login file. An empty entry (: as the first or last character, or :: in the middle) means "the current directory."
$HOME/bin
setenv PATH /bin:/usr/bin:/usr/local::$HOME/bin
Article 8.7 explains more about setting the path.
The most common problem with PATH is that, somehow, it gets deleted. This usually happens if you try to change PATH and do so incorrectly. When PATH is deleted, your shell can only find its built-in commands (1.10) and commands for which you give the complete pathname. Here's a demonstration:% setenv PATH Set PATH to null accidentally% lsls: Command not found.
Needless to say, this can be very frustrating - especially if you can't figure out what's going on. There are a couple of easy fixes. The easiest is just to log out and log back in again. (logout is a built-in C shell command, so you won't have trouble finding it. If you get an error message like "Not login shell," try exit instead.) Another fix is to read (44.23) whichever initialization file defined your PATH variable, usually .login for C shell users or .profile for Bourne shell users:% source ~/.login$ . $HOME/.profile
This will almost certainly give you some of your path back; the problem is that a lot of initialization files merely add a few "private" directories to a system-wide default path. In this case, just execute the system-wide initialization files first (if your system has them). Their pathnames vary:% source /usr/lib/Cshrc% source /usr/lib/Login% source ~/.login
The other common PATH problem is that users sometimes can't find the commands they want. This happens most often when someone writes a new shell script with the same name as a standard UNIX command - say, true. He or she tries to execute it and can't; in fact, all that happens is:% true%
After staring at the script for a long time, the user sometimes gets the right idea: the script is fine, it's the path that's wrong. The PATH variable will look something like this:% printenv PATH/bin:/usr/local:/usr/ucb:/usr/bin::/home/mkl/bin
The shell searches the PATH in order; therefore, it finds the system's standard true command before seeing the new one. The new command never gets a chance. You could fix this problem by putting the current directory and $HOME/bin at the head of the search path, in which case, commands in the current directory and your private bin directory will override the standard commands. However, that's not recommended; it's a well-known security hole.
So what is recommended? Nothing much, except: if you write shell scripts or other programs, give them names that are different from the standard UNIX utilities (44.21). If you really need an overlapping name, you can use a relative pathname (1.21) to specify "the program called true in the current directory":% ./true
Here are some related articles. You can search your PATH for a command with which (50.8), findcmd (16.10), and whereiz (4.10). Article 6.5 explains the C shell's path variable.
6.8 Shell Variables
Shell variables are really just the "general case" of environment variables (6.1). If you're a programmer, remember that a UNIX shell really runs an interpreted programming language. Shell variables belong to the shell; you can set them, print them, and work with them much as you can in a C program (or a FORTRAN program or a BASIC program). If you're not a programmer, just remember that shell variables are pigeonholes that store information for you or your shell to use.
If you've read the section on environment variables, you realize that we defined them in exactly the same way. How are shell variables different from environment variables? Whenever you start a new shell or a UNIX program, it inherits all of its parent's environment variables. However, it does not inherit any shell variables; it starts with a clean slate. If you're a programmer, you can think of environment variables as "global" variables, while shell variables are "local" variables. By convention, shell variables have lowercase names.
Just as some programs use certain environment variables, the shell expects to use certain shell variables. For example, the C shell uses the history (11.1) variable to determine how many of your previous commands to remember; if the noclobber (13.6) variable is defined, the C shell prevents you from damaging files by making mistakes with standard output. Most users insert code into their .cshrc files (2.2) to define these important variables appropriately.
To set a shell variable, use one of these commands:% set name=value C shell$ name=value Bourne shell
As a special case, if you omit value, the shell variable is set to a "null" value. For example, the following commands are valid:% set name C shell$ name= Bourne shell
This is important: giving a variable a null value is not the same as deleting the value. Some programs look at variables to see whether or not they exist; they don't care what the actual value is, and an empty value is as good as anything else. If you want to make the shell forget that a variable ever existed, use the unset command. Unfortunately, older Bourne shells don't have a command like unset:% unset name C shell$ unset name Bourne shell
If you want to list all of your environment variables, use the command printenv (Berkeley UNIX) or env (System V). [1] If you want to list all of your Bourne or C shell variables, just type set. Here's a typical report in the C shell:
[1] printenv and env are external (1.10) commands; they work with any shell.% setargv ()cwd /home/los/mikel/power/articleshistory 40home /home/los/mikelnoclobberpath (/home/los/mikel/bin /usr/local/bin /usr/ucb /bin /usr/bin .)prompt los%shell /bin/cshstatus 0term sunuser mikel
If you want to print the value of an individual variable, give the command:% echo "$variable-name"
(While the example above gives a C shell prompt, this command works in all UNIX shells.)
Whenever you need the value of a shell variable - not just with echo (8.6)- you need to put a dollar sign ($) in front of the name. You don't need the dollar sign when you're assigning a new value to a shell variable. You can also stick curly braces ({}) around the name, if you want (e.g., ${name}); when you're writing shell programs, this can often make your code much clearer. Curly braces are mostly used when you need to separate the variable name from what comes after it.
But that's getting us out of the range of interactive variable use and into shell programming (44.1).


6.9 Special C Shell Variables
[Sorry, no articles about bash and tcsh variables. This book focuses on the "base" shells, sh and csh. csh variables work in tcsh, and many work (in slightly different forms) with bash too. For a complete list, check your bash or tcsh manpage. -JP]
The C shell recognizes and uses environment variables, but it also uses a great many simple shell variables (6.8) to control its own operation. These variables don't need to be put into the environment so they can be passed to subshells (38.4), because every instance of the C shell always reads the .cshrc file (2.2). Simple shell variables set there are thus propagated to every C shell.
Many of the special C shell variables are simply used as flags; that is, they need not be set to any particular value. The shell simply tests whether they exist or not. They are set simply by saying:set variable
rather than:set variable=value
Here are some of the special variable names used by the C shell:
· The cdpath (14.5) variable stores a list of directories. You can cd to subdirectories of these by typing just the subdirectory name.
· If the echo (8.17) variable is set, the shell will show the command line, after all variable and history (11.7) substitutions, before executing it. (This is very handy for debugging scripts such as .cshrc.)
If the verbose (8.17) variable is set, the shell will show the command line after history substitution but before any other substitutions.
The Bourne shell -v and -x options (46.1) work like the verbose and echo variables.
· If the filec or complete variable is set, the shell performs filename completion (9.8). The fignore (9.9) variable makes filename completion skip filenames that end with certain characters like .o.
· The cwd (14.13) variable shows the absolute pathname of the current directory. The cd, pushd, and popd commands set it.
· The hardpaths (14.13) variable fixes errors in the cwd variable that occur when you cd through symbolic links.
· Use the histchars (11.15) variable to set different history characters than exclamation point (!) and caret (^).
· The history (11.1) variable stores the number of shell command lines to save. The savehist (11.11) variable stores the number of lines of shell history to be saved when you log out. This amount of history is saved in a file called .history in your home directory, and the lines are restored the next time you log in.
· If you set ignoreeof (3.5), the shell won't respond to the end-of-file character (CTRL-d) and will require you to type logout or exit (38.4) to log out. This can save you from ending the shell accidentally (or logging out).
· The shell can tell you about new electronic mail (1.33) or changes in other files with the mail (21.8) variable.
· Stop the > redirection character from overwriting files with noclobber (13.6).
· The noglob variable stops wildcard expansion (15.1). (There's an example in article 5.4.)
· Set nonomatch when you want the C shell to treat nonmatching wildcards like the Bourne shell does . (15.4)
· The notify (12.6) variable asks the shell to tell you right away if a background job finishes or is stopped.
· The list of directories that the shell searches for commands is stored in path (6.5).
· Your login name from the USER or LOGNAME (6.3) environment variable is also stored in the C shell variable named user.
· The shell's command-line prompt is set by the prompt (7.2) variable. (The PS1 (6.3) environment variable is the Bourne shell equivalent. You can set the Bourne shell's secondary prompt (9.13), too, in PS2.)
· The exit status (44.7) of the last command is stored in the csh variable named status and the sh ? (question mark) variable.
· If a job takes more CPU seconds than the number set in the time (39.3) variable, the csh will print a line of statistics about the job.