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 shift end
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.