next up previous contents
Next: Introduction to Unix Security Up: The C Shell Previous: Job Control

Special Files

An appropriate way to end this chapter is with a discussion of the special files recognized by the shell (often referred to as dot files because of their leading dots) One of these files, the .history, was covered in the section on command history. It held the last specified number of commands executed. The C shell has three more files that it recognizes, the .login, the .cshrc, and the .logout files, which are all found in the user's home directory (~/). The .login is read by the shell at the start of a session, or more precisely, at login. This file should contain commands that are only to be executed at login, perhaps running a welcome message or the date. Any environment variables, such as the path, should be set here as well. An execption to the rule of the .login file only executing at login can occur in X windows when using xterm. If an xterm is started with the -ls flag, the resulting terminal window will be a login shell. This seems a harmless enough situation, there is no real problem with redefining variables with the same value or even with displaying a welcome message in each terminal window (if one is displayed in the .login file), but some subtle problems can arise. One problem that comes to mind is the following. On most systems, the path will be set to some basic value (such as, /bin:/usr/bin:/usr/local/bin: etc...) so that if there is not a proper path set by the user, basic commands like vi will still work. Most users define their path in their .login script as:

set path = ( $path /usr/public/bin ~/bin . )

Now clearly what will happen if the .login script executes on each invocation of a shell is that the path will continue to grow. This is not a pretty thing to see when echoing the $path variable, but even worse, it can begin to affect the performance of the shell.

The .cshrc file is executed each time a new shell is invoked and thus any variables wanted for each shell should be defined here. Even though a global definition can be set in the .login file, the definition can be changed at any time and it is always wise to define important variables, like noclobber, in the .cshrc file. It is possible to define the path variable in the .cshrc file, but if any additions have been appended to the path in any other shell, they will be overridden within the current shell. This fact may also assure that the path will be safe from unsetting but the former is usually the case. It is up to each user, how and where the path will be set. The .cshrc is an ideal place to define aliases.

The .logout file is a file not used by many. Most tasks are handled nicely by the shell during logout and thus it is not necessary to handle them in the .logout script. There are a couple of good applications for the .logout shell however. The first is for handling a safe deletion system. A user can make a directory called ~/tmp.dump and then define a command called del with the following script:

foreach file ( $argv )
   mv $file ~/tmp.dump

Instead of the files being deleted, they are stored in the tmp.dump directory, and undeleting is as simple as copying them later from this directory. Since files will accumulate and start to dig into the users disk quota, they should be removed (officially deleted) at some point. The .logout script can be the ideal method of handling this task. The directory can either by cleaned completely each logout or a more sophisticated script can be written to discard files after they have been in the directory a certain period of time. There is no reason that external scripts can not be run from the .logout (or any DOT file for that matter) using the source command. Another reason to use the .logout file comes from personal experience. There exists a program called plan which is a date planner with built in alarms. In order to keep track of scheduled alarms, a daemon process is initiated when X windows is started to handle this. When X is exited and the shell is exited and this special process does not die. Fortunately, the package comes with a special program to kill the process, which when added to the .logout produces the desired result of killing the daemon at logout.

next up previous contents
Next: Introduction to Unix Security Up: The C Shell Previous: Job Control

Douglas M Gingrich
Mon Apr 27 15:25:49 MDT 1998