Dotfiles (AC-16)

Table of Contents || Revision history || Copyright information

Customizing Your Session


The set of files used to describe session initialization procedures and store user customizations are commonly referred to as "dotfiles". These files can be used to customize screen appearance, shell behavior, program specifications and aspects of your Athena session. Most dotfiles are text files, although some exist in other formats. Dotfiles generally contain one command per line and are stored in your home directory. Dotfiles usually have names that begin with a period, hence the name dotfiles. You are given some dotfiles that are necessary for you to be able to login when you get your account.

You may not have even noticed the dotfiles in your account because files that begin with a dot are not listed when the command ls is issued. To view dotfiles use the command ls -a. You may have many more or less dotfiles in your account than this example shows. It all depends on what programs you have used and what, if any, customizations you have made to them. Many programs create dotfiles to store information and preferences.

athena% cd ~

athena% ls -a

. .login .zephyr.vars

.. .message_times Mail

.mh_profile .mozilla OldFiles

.Xresources .netscape Private

.cshrc .startup.X Public

.desktop_indy .zephyr.subs

This document covers

Below is an overview of what happens by default when you login to a workstation. Some of the files mentioned are not in your home directory. Those files are located in a central location for updates at a future date without you having to make changes to your dotfiles each time there is a slight modifications to the system.

The sequence of events in a terminal style session (dialup) will be covered later in this document.

flowchart of login sequence

Dotfiles Descriptions

The following section provides detailed descriptions of the files and programs associated with session initialization. This includes dotfiles and the programs that source them. In addition it contains links to sample customizations that appear in later sections.


Xlogin is the program that is running on a workstation that is not in use. It is the program which allows you to enter your username and password. In addition it provides many login functions and allows the user many options.

For a standard session Xlogin acquires Kerberos tickets and tokens, attaches the users home directory, adds the user to /etc/passwd and /etc/groups then sources /etc/athena/login/Xsession. After logout Xlogin restarts and waits for the next user to login. Kerberos tickets and AFS tokens are what authenticate identity and allow access to lockers and files.

Nonstandard sessions are possible from Xlogin by selecting them from the login options menu. You can specify login without customizations in which case user customizations files are not sourced and your session is configured as the default session. The files not sourced when you select login without customizations are:

It is also possible to login with terminal mode behavior. This means there are no X windows, just a shell; which,is similar to logging in over dialup. More information on this kind of login is available in the section on terminal style logins.


This file is located on the workstation's hard drive. etc/athena/login/Xsession makes Athena modifications to the keymap, if necessary, and sources the standard Athena xsession file unless ~/.xsession exists. During logout procedures etc/athena/login/Xsession destroys the Kerberos tickets and prepares for the next user to login. Then Xlogin regains control.


This file controls most of the login sequence as follows:

  1. /usr/athena/lib/init/xsession checks for the file ~/.hushlogin. If that file exists login status messages will not be displayed.
  2. The XSESSION environment variable is set to indicate an X session as opposed to a terminal style session. This variable is used by later files to determine the proper login procedures.
  3. Source ~/.cshrc
  4. The X Windows system is configured through the ~/.Xresources file.
  5. Then a windowmanager is started. The default windowmanager is Motif Window Manager (MWM), but it is possible to select another windowmanager.
  6. Then /usr/athena/lib/init/Xsession starts a selection of programs, all of which can be avoided through alterations to the .environment file.
  7. The .startup.X file is sourced. This file is where programs that are to be run at start-up should be executed.
  8. Finally the xsession file gets ready for the user to logout. When the user logs out, the .logout file is executed and control is then returned to the /etc/athena/login/Xsession.


By existing ~/.hushlogin suppresses messages from the login script. This means there will be less information presented in your console window. Information about the number of mail messages you have or other data that comes from outside sources will not be suppressed, but ~/.hushlogin will suppress "Starting initial xterm..." messages and other login status messages contained within the dotfiles designed to let you know how the login is progressing.

A word of caution, do not create this file until modifications to other dotfiles are completed. Status messages may help you find where problems occur during login. This makes it much easier to fix any mistakes you might make.


This file simply calls the system-wide user initialization file /usr/athena/lib/init/cshrc . If that file is not available for some reason ~/.cshrc sets a few variables.

The standard version of ~/.cshrc that is given to all new users is in /usr/prototype_usr/.cshrc

DO NOT modify your ~/.cshrc file as you will not get updates made to the system-wide file. You should use the ~/.environment and ~/.cshrc.mine files to modify settings and make customizations. Changing the ~/.cshrc file is not encouraged or supported.


This file is called by the ~/.cshrc. /usr/athena/lib/init/cshrc is located in a central place so it can be updated for system updates without requiring any user changes.

It does two main things in the process of setup:

  1. Environment Setup -- sets UNIX environment variables, command search path, etc. This step is usually preformed only once a session.
  2. Shell setup -- sets C shell variables/aliases, command prompt, etc. This step is preformed every time a new C shell process is started (ex: whenever an xterm is started)

The cshrc file sets the following shell variables :

unmask 077

set the default file permissions such that only the user can read and write files created in this session

limit coredumpsize 0

keeps programs from dumping core files.


set the default Athena search path set athena_path=( /srvd/patch /usr/athena/bin /bin/athena/usr/bin/X11/usr/new /usr/ucb/bin /usr/bin /usr/ibm /usr/andrew/bin)


describes what directory to find the appropriate versions of programs for the type workstation you are using. set bindir=${hosttype}bin Each kind of workstation has it's own bindir where binaries for programs are kept that will run on that kind of workstation. For the suns the bindir is sun4bin and for the Linux the bindir is linuxbin.


tells where to look for manpagesset athena_manpath=/usr/athena/man:usr/man


set your home directory ~


Protects overwriting some kinds of files


set the prompt in your xterm


set the number of commands saved in history (think scrollbars)


The path searched for directory changes

Then the following environment variables are set:


Makes the more command work.


Set the default "home" directory.


Set the default line editor to emacs


Set the edfault screen editor to emacs


Set the default search path for man pages


Used by add when adding lockers to modify the path and manpath appropriately.


Sets the default printer.

Sources ~/.environment to set user specified environment variables

Next several aliases are set for your convenience:


Renews your Kerberos tickets (that expire in 10 hours).


changes the terminal setting


resizes an xterm intelligently


logout from any shell, not just the initial one


attaches a locker and adds the locker to the path and manpath


adds a class locker and runs appropriate related start-up scripts


same as setup but for X windows sessions


same as setup but for terminal sessions


undoes everything setup did


shows message about mail on Athena that's in /usr/prototype_user/README.mail


aliased to Mail


makes it possible to append to an environment variable (ex: adding a path to MANPATH)

Finally your .cshrc.mine is sourced to load user specified customizations and control is returned to /etc/athena/login/xsession.


The ~/.environment file is a user created file. Commands that set shell and environment variables and that add frequently used lockers to your path are placed here. In addition this file can be used to select a different windowmanager, skip standard startup activities, customize printer options, and set default editor selections. All customizations made in this file are done only once a session and should be appropriate for both window and tty sessions.


.cshrc.mine is a user created file where custom variables for the c-shell are set, aliases are created and other customizations specified. This file was created on Athena to encourage users not to alter the .cshrc file. The only shell variables that should not go here are the ones that control the session (session controlling shell variables are located in ~/.environment because they need to be sourced earlier in the login process).


The xsession runs xrdb on ~/.Xresources if the user has created the file and it exists in the home directory. This loads the preferences for X applications. ~/.Xreources can be used to change colors, specify locations, fonts, and other application specific settings. X resources are stored in a database, not as variables.


This user created file is sourced near the end of the session initialization by the xsession. ~/.startup.X is where you can specify programs you want to run upon start-up. Some common files to start at the beginning of a session are xmh and xclock. This file will only be sourced in X window sessions. ~/.startup.tty is for programs to be started in terminal style sessions. Commands put into this file should have an & after them unless the command will finish quickly (inc, fortune, etc...). Otherwise the initialization will come to a halt until the program exits, you probably do not want this to happen. emacs, xclock,xmh and netscape are programs that will not exit without user interaction. This means your session initialization will not finish and logging out may be difficult.


This file is sourced by the /etc/athena/login/xsession after logout is typed. ~/.logout can be used to run programs or scripts just before the session is over. However, since user input is halted at logout, the scripts run should be self-contained with no stdin.

Common Customizations:

Do NOT make changes to ~/.xsession ~/.cshrc or ~/.login. Any changes to these files are made at your own risk. The session activity can not be guaranteed or supported as you will not receive changes to these files automatically. This may render you unable to login and unable to gain assistance to do so.

This section includes warnings about common errors and useful info about the dotfiles that can be used to customize an account. Read all the way through this section before making changes, it is important to know what kinds of customizations go in all the files before changes are made. This ensures customizations will be put in appropriate locations. Also be sure to read the appendices on testing dotfiles and how to recover from errors in dotfiles at the end of this section. It will save you a lot of time and effort. Printing out a copy of this document before trying to customize your dotfiles is reccomended; it'll be handy to have a hard copy around if you break things such that you can't log in. There is also a chart in Appendix R that lists common customizations and what dotfiles you use to make those changes.

Many of these files do not already exist in your home directory. To create them use an editor, such as emacs, and save the file in your home directory with the appropriate name.

emacs ~/.dotfile

athena% emacs ~/.environment

Your Path

As mentioned above you can customize your path. The path is used when you try to run executable files (programs) to find the program. Things listed first in your path will be where the system looks first for the program you are trying to run. If there are multiple versions of the program, the first version found will be the one used. Be sure to take this into account if you decide to customize your own path. The default path is listed by the variable $athena_path To view what is currently in $athena_path or $path:

athena% echo $athena_path.

athena% echo $path

An example path:

. /usr/athena/bin /mit/games/arch/$bindir/bin

The dot suggests that the system look in the current directory first, then it looks to the Athena default path (usr/athena/bin). Finally the system looks in the appropriate bin for your workstation in the games locker. The variable $bindir is set earlier in your session initialization and corresponds to the type machine you are using.

If you wish to add lockers or specific directories to your path permanently, you can use your ~/.environment file as described below to customize your path using the add command.


The ~/.environment file is used to add lockers, skip some start-up activities and set environment variables. Remember all commands are case sensitive so be sure to copy capitalization exactly. Here are a few simple customizations you may wish to put in your ~/.environment file:

setenv EDITOR emacs

set the default editor

set skip_xlogout

skips the logout button (be sure you have another way to logout)

set skip_xss

skips starting the default screensaver, xss.

set skip_dash

skips the dash menubar

set skip_x_startup

skips startup commands that check mail, olc messages, start zephyr, send message of the day

set skip_tty_startup

same as skip_x_startup for terminal sessions.

set skip_initial_xterm

should be used carefully, you most likely don't want to leave yourself without an xterm or the ability to get one at start-up, so only use this command if you plan to start another xterm in your ~/.startup.X file or you can get an xterm through dash or your windowmanager.


/mit/windowmanagers/$bindir/twm will change your default windowmanager from mwm to twm. There are many other windowmanagers located in the windowmanagers locker. add windowmanagers; cd /mit/windowmanagers/$bindir/ to take a look at the windowmanager choices available. If you decide to use a windowmanager from here include the line add windowmanagers in this file

setenv LPROMPT "-h -z"

will prevent the printing of the header page when you print (to conserver paper) and will enable the sending of zephyrs to you when your document is finished printing or if there is a printer error preventing printing.

add lockername1 lockername2 lockername3 /var/local/directory...

is how to add lockers and directories to your path, manpath and get access to files in those lockers you have permission to read. It is much faster to list all the additions on one line so the script only runs once.

add -f lockername4

The -f option of add adds the locker or directory to the front of your path.

limit coredumpsize 0

is the default setting that keeps core files from filling up your directory. If you are doing programming and wish to see your core files you can change the 0 to whatever size you deem appropriate for your work, remember that core files are often large and fill your quota quickly.

There are many more environment settings than those listed above, but it is beyond the scope of this document to cover them all. To find out more about environment settings and other dotfile related topics, take a look at Appendix H.

Commands that you want run each time you login, for both window and tty sessions should generally be put in ~/.environment. However this is run before ~/.cshrc. If what you want to run depends on these files being sourced the command should be put in ~/.cshrc.mine.


The ~/.cshrc.mine file is used to set shell variables and aliases

alias dir ls

Causes the command ls to work when you type dir, a useful thing to do if you're not used to UNIX commands.

In general it is convenient to shorten commands you commonly use. If you have a lot of aliases you may want to create a file ~/.aliases to put them in, then all you need to do is put the following in your ~/.cshrc.mine file and the ~/.aliases file will be sourced.

athena% source ~/.aliases

To set the prompt in an xterm:

set prompt = "New Prompt"

athena% set prompt = "My Prompt"


There are more things that can be done with the ~/.Xresources file than can be covered in this document. The Xresources file contains information on how you want the programs you run to look and behave. The general form for entries in your ~/.Xreources file is:

program*resource*subresource*...*subresource: value

Capitalization is very important as all Xresources are case sensitive. Some capitalization in Xresources is not intuitive. You can find information about the Xresources for most programs by typing:

man programname

athena% man zwgc

There are a few common types of customizations you can make in your Xresources files. Some of them are changing the colors of applications, specifying locations where applications will appear, the fonts applications will use and other program specific customizations. Here are some examples using zwgc ( zephyr).*geometry: +c+c*geometry: +0-0*geometry: +0-0*geometry: -0-0*geometry: -0+0*geometry: +0+0

This set of commands will cause windowgrams (zephyrs) that are personal messages to appear in the lower right hand corner of the screen. Login and logout notices, which are sent if you use znol, will appear in the lower left hand corner of the screen. Windowgrams sent to a class or instance called b5 will appear in the center of the screen. Windowgrams sent to instance foo will appear in the upper right hand corner of the screen, and windowgrams to instance bar will appear in the upper left. The geometry values can be set to numbers other than zero. The first number corresponds to the horizontal distance from the corner and the second number corresponds to the vertical distance from the corner. Thus if you set the geometry for personal zephyrs to -10-0, the windowgrams would appear flush against the bottom of the screen 10 pixels form the right hand side of the screen. Be careful when setting geometry because the measurements are all from the sides (except +c+c which is a special case for centering) and screen sizes vary.

Zephyr is not the only program for which geometry can be specified. Geometry can be specified for most any program. Zephyr is one of the most complicated because you can specify subresources of instance names, classnames and usernames. To use geometry for most other programs:

programname*geometry: 20x20+0+0

The 20x20 refers to the size of the window. It is important to be careful when setting the size of programs, such as zwgc, that vary in size since you could lose content. The 20 actually means 20 pixels, so this would be a very small window.

Screen location is not the only thing that can be specified in Xresources, another popular customization is to change the color of programs on your screen:*foreground: white*background: green

XTerm*foreground: black

emacs*foreground: blue

XTerm*background: blanchedalmond

emacs*background: black

This will cause your xterm to have black text and a background color of blanched almond. Emacs, on the other hand, will have a black background and blue text. Windowgrams sent to class or instance help or from someone with the username help will be white on green. To find a list of colors available take a look at the following file:

/usr/lib/X11/rgb.txt on Sun workstations

There are a nearly infinite number of options with Xresources, here are a few more that will give you a thin scrollbar on your xterm that saves up to 500 lines of text, and an xclock with a different font.

XTerm*scrollBar: true

XTerm*saveLines: 500

XTerm*Scrollbar*thickness: 5

xclock*font: -*-helvetica-*-r-*-*-14-140-*-*-*-*-*-*


This file should contain whatever commands you would type at your prompt, one per line, for the programs you wish to be started upon initialization. Some common programs to start are xclock, xload, and xmh. Note that starting anything time consuming/computationally intensive, such as a web browser, can cause your initialization sequence to take a long time. If you only use a program occasionally it is generally better to start the program yourself when you want to use it.

The session initialization sequence will come to a halt until the program has exited. If you are simply checking the weather, that will finish quickly and no ampersand is needed, however if you are starting a web browser all initialization will halt until you exit the browser. Put the ampersand (&) after the command to solve this problem.

programname &

mozilla &


This file runs after you type logout to end you session. A common customization is to:

cd /mit/$USER

(echo "*** Logged Out" `date` on `hostname` "***") > .plan

cat .plan

The ~/.logout file commands must apply to both X and terminal sessions. ~/.logout does not run within and xterm window so commands such as clear , resize, exit, etcetera will fail. Also, do not use commands that require user input since the ~/.logout file is run from the console window in X sessions and there is no method for user input.


You do not need to put anything in this file, ~/.hushlogin just has to exist to stop progress messages in the course of your login to be suppressed. The easiest way to do this is to issue the command:

athena% touch ~/.hushlogin

This command will create the file and you need do nothing more to your ~/.hushlogin file. A word of warning, it can be helpful, when working with your dotfiles, to have the progress messages so you can tell where you are having problems if your dotfiles break when you try to login. You might not want to create this file until you are done with other customizations and are sure your customizations work. Progress information can be helpful in determining where problems are in the initialization sequence. Also, the "message of the day" (motd) will not be sent with a quiet login. If you decide to create ~/.hushlogin file you should restore the motd as the messages are important messages from accounts. Add this command to your ~/.startup.X and ~/.startup.tty files:

get_message -new -zephyr

Other Dotfiles


This file is generally used to put information you want people to see when you are fingered. If you want to make information avaliable this way the file must be publicly readable.


File commonly created if you use a lot of aliases to keep the ~/.cshrc.mine file more readable. If you make a .aliases file be sure to out this line in your ~/.cshrc.mine file:

source ~/.aliases


This file is used by the program zaway. ~/.away contains the message that is sent to people who zephyr you when you use the zaway program. For information about and how to customize zaway issue the following command:

athena% man zaway

~/.desktop_indy ~/.Sgiresources and ~/.startup.sgi

Sgi specific files. The equivalent of ~/.startup.X for the sgi's is ~/.startup.sgi. See information in .startup.X for details. ~/.desktop_indy is a file created by the windowmanager to store information about your screen setup and preferences. ~/.desktop_indy and .Sgiresources are similar to ~/.mwmrc, but is not user customizable. The customizations are made through the customizations menu the windowmanager provides.

Note: SGI workstations are no longer in the general use clusters and are not supported in Athena releases past version 9.1.

~/.emacs and ~/.emacs.19

Used to customize the program emacs. For more information refer to the document Emacs on Athena.

~/.mailcap, ~/.maillock and ~/.mh_profile

These are not user customizable files. These files are used by some mail programs and should not be altered by hand.


This file is used to store information about discuss meetings. For more information about discuss refer to the document Discuss on Athena.

~/.mozilla and ~/.netscape

There are a lot of dotfiles that Mozilla and other web browsers create, these are only a couple. Most of the can be ignored. Some of them, like the history files, may become large. The history can be deleted, but you will lose the record of where you have been before. .mozilla and .netscape are directories where all of the browser's customization and history files are stored.

~/.newsrc, ~/.oldnewsrc and others

These are files created by news readers that contain information about your preferences, what groups you read and other state information. These files are not user customizable in most cases. Read the documentation on your newsreader to find out what files are user customizable. Some news readers create directories that contain their customization files.

~/.twmrc and ~/.mwmrc

Customization files for windowmanagers, see appendix D on windowmanagers for more information about these files and windowmanagers in general.


Contains information about the zephyr classes and instances to which you subscribe. You do not have to edit this file by hand, the zctl add and zctl delete commands write information to this file automatically. Information is stored in the format

Class, instance, recipient

Your file might look a bit like this if you subscribe to instance help, instance b5, and class my-friends.






See the Document Zephyr on Athena for more information about zephyr, zctl commands and zephyr related dotfiles.


Contains the information you provide with the zctl set command. This is zephyr's way of letting you set variables and customize its behavior to some extent. Signature and exposure information is kept here.


Describes how windowgrams will appear on your screen. The prototype of this file is located in /usr/athena/share/zephyr/zwgc.desc This can be copied into your home directory and modified. ~/.zwgc/desc is a csh script, unlike most of your other dotfiles.

Terminal Type Mode (ttymode) Login:


A terminal style session is the type you get from dialup or choosing terminal-style session as a login option from Xlogin. This runs xterm -ls, which sources ~/.cshrc and runs ~/.login:

flow chart of startup activites for a
TTY session

Start of a Terminal Style Session

For a standard terminal (tty) session, the system starts the special "login shell" and goes directly to the Environment Setup phase, Environment Setup is exactly the same in window and tty sessions.

If you have a file named ~/.hushlogin (it can be an empty file), then the system will not echo status messages about initialization (i.e., messages such as "Setting up environment..." will not be echoed to your screen during start-up). This speeds up tty-session initialization especially over slow dialup connections.

The environment setup section of initialization is the part associated with the files ~/.cshrc, /usr/athena/lib/init/cshrc, ~/.environment, and ~/.cshrc.mine. All of these files do the same thing in terminal sessions. Your environment and path will behave the same and lockers are attached normally. Anything you could do in an xterm, you can do normally in a terminal style session.

This file calls the system file /usr/athena/lib/init/login. Although this file simply calls another file, the ~/.login file is necessary because standard UNIX expects to find a login initialization file in your home directory. ~/.login is the rough equivalent of the .xsession file

Warning: Do not make changes to ~/.login. Make changes to the tty initialization through the ~/.environment and ~/.startup.tty files.

The standard version of ~/.login that is given to all new users is found in /usr/prototype_user/.login.

The file /usr/athena/lib/init/login embodies two major steps in the session setup:

Make a temporary home directory if necessary

In this step, the system checks whether you have access to your home directory. If not, the system offers to create a temporary local directory, warning that work may be lost. You can terminate the session at this stage by answering the system question to this effect.

Set up tty device characteristics (e.g., VT 100 emulation)

Here, the system does some setup activity related to the particular device being emulated, and prompts for the DISPLAY variable if the session originated by an rlogin or telnet.

Tty-oriented Start-up

Activity begins in earnest. Once the "tty" session start-up activities run, you can interact with the login shell. The start-up activities can be overridden through the ~/.startup.tty file; see below. Any text on a line after the # character will be ignored by the interpreter.

Run standard start-up activities (check mail, start zephyr, etc.)

In this step, the system runs standard activities that most users want to have run automatically:

set ignoreeof

^D won't log you out


tries to start a zephyr client

from -t -n

checks for new mail

(olc who &) >& /dev/null

if you have a question pending in olc, notifies olc that you have logged in

To override any one of these steps, you must override the whole set, then include the ones you want to run in your ~/.startup.tty file (see the next step). To override the default set of steps, include the following statement in your ~/.environment file: set skip_tty_startup

Run user-specified start-up activities (if file ~/.startup.tty exists)


Start-up activities for tty sessions (e.g., inc, zwgc -ttymode, etc.). This is the equivalent file to ~/.startup.X.

In this step, the system session file runs all of the commands contained in the user file ~/.startup.tty. For example, ~/.startup.tty might contain:


check who is online


incorporate new mail

Note: In the ~/.startup.tty file, run in the background any command that will not exit quickly. To run a command in the background, put an ampersand, & after the command. In the examples above, this is not necessary because they will exit quickly. Using and ampersand is necessary with emacs; otherwise, the login process will stop while in wait for emacs to exit. This will not happen without user input, the login procedure will never stop and you will not gain control of your shell or anything else. This could make it hard to logout.

User interacts with system

Now you are logged in and your interactive session can begin. When you want to terminate the session, type logout at the shell prompt.

User issues "logout" command

Note: When you log in for your next Athena tty session, type the following command at the prompt:

athena% zctl set fallback true

You need issue this command only once in your Athena tty-session career. This sets the fallback variable so that zephyr runs in tty mode, by default, when you log into a tty session.

Tty-oriented Logout

When you logout, a few tty-oriented system wrapup activities are conducted after the session file is completed (e.g., deactivating the workstation and detaching lockers), but these are not oriented toward the specific user's session. You can, however, specify your own wrapup activities in a ~/.logout file.


To have the system run any special post-session activities, you can include commands in the file ~/.logout. Remember that the commands in this file will also be used for "window" session logout. See section on .logout .


Appendix A: Shells

A shell, a command interpreter, tries to make sense of what you type and relay that to the operating system. A shell is automatically started in each xterm window that is created. Basically, whatever you type at an xterm is read and interpreted by the shell and then passed along to the operating system to be executed.

There are a lot of customizations that can be made to the shell, aliases to shorten commonly used commands are just the most common. The shell finds the locations of programs, interprets expansions (ex ls *.exe), substitutes values of shell and environment variables and interprets aliases.

As you probably have already figured out, you can have multiple copies of the shell running at any given time. Some programs, such as xterms, start them. Every time a shell is started associated customization files are read. The default sell is tcsh but there are other shells that exist that you can use instead.

Appendix B: Tcsh Special Characters

Tcsh is the default Athena shell. Tcsh has some special characters that you should be aware of when making aliases or anything else that will be interpreted by the shell.


An abbreviation for the home directory of the user foo is /mit/foo/


Any single character, kind of a fill in the blank thing


Any file name or part of a file name. * means all files, x* means all files starting with x, x.* means all files beginning x. and *.x means all files ending in .x. It even works for x*x where you get all files beginning and ending in x. This is a lot like ? but there's not a limit on the number of character to fill in with.


Used to group things. Anything within the "" will be treated as one word except variables which are still expanded.


Same as above but won't expand variables.

[ ]

Encloses list of character options: *.[ch] will list all files ending in .c or .h

{ }

Does it for words ls ~/1.00/{prob1, prob2, prob3}.c

( )

Encloses commands to be executed in a sub shell.


Separates commands you want run on a separate line.


Takes output of a command and writes it to a file.


Supplies the file as input to a command ex: zwrite friend < file.


Takes the output of one command and makes it the input of the next command.


If you want one of the above characters as itself put a / in front of it.

Appendix C: Variables

Variables are used to store values that can be used by other commands and programs. These values can be set and read from the shell or through dotfiles. There are 2 kinds of variables, environment and shell. Shell variables are set by

set variablename=value

set prompt="athena%"

Environment variables are set by:

setenv variablename value

setenv TERM VT100

To display them:

athena% echo $prompt

athena% echo $PRINTER

The difference between environment and shell variables is that shell variables can only be read in the shell in which they are set while environment variables can be read from any shell.

There are some variables that programs expect to be able to find called standard variables. Some examples of these are $PRINTER, $prompt , $bindir, $EDITOR, and so forth. It is possible to make your own variables and give them values just as you would a standard variable.

There are also variables that do not get a value, they just get set or unset (turned off or on). Example:

set lineedit

The first time $lineedit is set lineedit is turned on, the next time $lineedit is turned off.

To see all the variables currently set type the following for shell and environment variables respectively:

athena% set

athena% setenv

You can customize your account temporarily by setting variables from a shell, but to customize permanently you must make these changes in the appropriate dotfiles which is covered in the customizations section of this document.

Appendix D: Windowmanagers

One of the most common changes made to dotfiles is switching the default windowmanager to something else and/or making changes to your windowmanager settings. The variable $windowmanager determines what windowmanager will start up when you login. You can set this variable with the following command in your ~/.environment file.

setenv windowmanager mwm

Mwm is the default windowmanager, but twm is another popular windowmanager. The windowmanagers locker contains information about various windowmanagers and the standard dotfiles for many of them, as well as the associated binaries (program). The files associated with mwm and twm customize the key bindings, menus, appearance, and other settings for the windowmanager.

The default versions of the windowmanager start-up files are a good place to start when making your own customizations. You can copy these into your home directory and make your own alterations.



When making changes to your windowmanager it is not necessary to logout and log back in to see the changes. Simply choose the menu option restart mwm (or twm) from the root pop up menus or from an xterm :

athena% add consult; punt mwm

athena% mwm &

If you kill the windowmanager all uniconified windows will be visible on the screen and may cover an xterm. You will not be able to move, raise or lower windows. Be sure an xterm will remain visible.

The windowmanager may display unusual behavior if you made an error in your customizations. The windowmanager may fail to start or be in a strange configuration. If there is an error in a windowmanager file it stops sourcing the file at that point. Usually there will be an error message in the console window that says what line failed.

If it is hard for you to get work done due to the new configuration, login without customizations to fix the problem. Be sure to save the old copy of your dotfiles so you can go back to that if you can not find the error.

Appendix E: Testing Dotfiles

The best way to avoid having to use the next section on trouble shooting dotfile errors is to test them ahead of time. Aliases and variables can be set from the command line. Before adding them to your dotfiles try them out first on the command line. Note that some of these won't do anything if set after start-up. Setting skip_dash after you've already logged in will not cause any noticeable change, especially if you are using the gnome based panel interface. Setting and alias then testing the alias, however is very useful.

Source a new or changed login related dotfile from an xterm before logging out. This will make sure there are no errors that will keep the file from completing its tasks. Dotfiles may not do exactly what you think they will when you login, but if you test the dotfiles first and there are no failures, at least, you should be able to login successfully. The testing is done by:

source .dotfile

athena% source ~/.cshrc.mine

Aliases can be tested individually at the prompt

athena% alias dir 'ls -l'

Then simply type dir at the prompt and see if the alias does the right thing. Setting variables can be done in much the same way. Here some examples for shell and environment variables respectively:

athena% set prompt="my new prompt "

athena% setenv PRINTER ajax

Whether the variable was set or not should be easy to test in this case. Some variables are harder to test whether they work or not without logging in again, but you can always check the value of a variable to make sure it got set.

athena% echo $prompt

athena% echo $printer

For program related dotfiles, save the old dotfile under a new name before making changes. Then make your changes and try running the program with the new dotfile. This way you're sure to have the old version to go back to and look at to see where you made changes or use until you can fix the new version. Saving the old versions of all your dotfiles until you get the new ones working is generally a good idea.

To test changes to the ~/.Xresources file use the command below. After you have done this you must quit and restart programs to see any changes made to their settings, otherwise your programs will continue to run under the old settings.

xrdb -load ~/.Xresources

You can also test changes to your windowmanager by quitting and restarting. Be sure to save the old version just in case the new one doesn't work. Not having a working windowmanager can make it difficult to get work done. See the appendix on windowmanagers.

You should change and test just one command at a time, this makes it much easier to find and fix errors.

Appendix F: Troubleshooting Dotfiles

While making customizations it is possible to make mistakes that will make it difficult for you to login. Here are a few tips on how to deal with this, should it happen. Proper testing ahead of time can help avoid most mistakes that will make it hard to login, but there are always exceptions.

If you can't login normally try logging in without customizations. As long as you stick to dotfiles mentioned in this document as user alterable, this should work. Another option is to login for a terminal style session. Also, it is best to test terminal mode customizations when you have access to Xlogin so that if a mistake is made you can login without customizations. There is no easy way to login without customizations using a terminal style login.

Once you have logged in without customizations the first thing to do is figure out where the problem is located. The easiest way is to modify only one dotfile at a time and try logging in with the new one, then you know what file the mistake is in. If you have already made changes to many files, try putting this at the top of each of your dotfiles (except ~/.Xresources and ~/.zwgc.desc) you made changes to:

echo "sourcing dotfile foo"

and this at the end

echo "done with dotfile foo"

Replace foo with the name of the dotfile. During session initialization the messages will appear in the console window so you can tell what dotfile is being sourced at any given moment. You'll know which one breaks the system by noting which one starts but doesn't finish. Looking at the flow charts of session initialization while this is happening will help it all make sense.

Once you know which dotfile is causing the problems, take a look at the dotfile and see if you mistyped anything. If not, see if you made a logic error or some other mistake. If you still can't figure out what is wrong you can copy a day old version of the file (if the dotfile existed before you made changes) from your OldFiles directory. Once you have a working file, try adding back in the changes one at a time.

Another option is to "comment out" sections of the dotfile that you changed to narrow down where the problem is located. This is done by putting the character # in front of each line you wish to be ignored. The # can simply be deleted at a later date to have the line sourced again. By commenting out changes and adding them back in one at a time the error can usually be located.

If all else fails, get the default user dotfiles and copy them into your account. See appendix I.

Appendix G: Logging Out

Sometimes dotfile errors or a windowmanager failing can make it difficult to logout. Here are some ways to logout.

Appendix H: Learning More

To find out more about dotfiles there are several things to do. There is a minicourse about dotfiles, you can read manpages and documentation about programs to find out about associated dotfiles, there are OLC stock answers and you can ask questions there. Zephyr on Athena has a section on its dotfiles and other documents contain information on other program specific dotfiles.

One of the best ways to learn about dotfiles is to look at other people's dotfiles and see what has been done. Do not copy someone elses dotfiles into your home directory. Some customizations are user specific and could cause your login to fail. The best way is to read other dotfiles and add things you like into your own. Make sure you understand what a command does before adding anything to your files.

Finding dotfiles is easy, there is a locker named dotfiles that contains dotfiles that people have made in the past. Take a look at them and see if anything there looks like it could help you. This is not a supported service and there are no guarantees, be careful and only make changes to your own dotfiles that you understand. read the file /mit/dotfiles/README for more information about the dotfiles locker and its uses.

You can learn a lot about X Resources by reading the X manual page and the manual pages for programs you wish to customize. To view the manual page for X windows, zephyr, ls, or other programs or commands use the following commands. For most manpages simply use the name of the program or command you would type at the prompt.

man programname

athena% man x11

athena% man zwgc

athena% man ls

Finally there is a minicourse taught about dotfiles, check the schedule to find out when the next course is being taught.

Appendix I: Default Dotfiles

If you make errors in your dotfile changes here is where you can find some standard copies of customization files. If you do not wish to make changes to these files it is not necessary to copy them into your account. Also, in some cases it can be dangerous to make changes to these files. For xsession and cshrc the files are listed here so that you can take a look at the files and make your customizations in the appropriate dotfiles in your account, do not make your own ~/xsession or ~/.cshrc.

/usr/athena/share/zephyr/zwgc.desc standard zephyr settings

/usr/prototype_user/.login standard ~/.login file

/usr/athena/lib/init/xsession standard ~/.xsession file

/usr/prototype_user/.cshrc standard ~/.cshrc file

/usr/prototype_user/.mh_profile standard .mh_profile file

Appendix J: Aliases

Here are some examples of useful aliases you may want to put in your ~/.cshrc~/.login.mine file. Anything on a line after a # are comments . Comments are ignored when the file is sourced. Comments are useful to explain what purpose commands serve.

# Misc. Hacks

alias cleanup 'delete -v *~ .*~ #* #.*' #deletes autosave and

#other files to reduce quota

alias del 'delete -v' #makes the delete command verbose

alias exp 'expunge -v"

alias f 'finger' #shortens commands

alias hi 'history'

alias motd 'get_message' #displays the message of the day

alias mroe 'more' #makes a common typo work anyway

alias so 'source' #shortens a command

alias fastmouse 'xset m 30 6' #sets the mouse speed

alias ns 'netscape &'

alias fi 'finger \!*@mit' #finger username in mitdir

alias thesaurus 'thesaurus \!* | more' #change thesaurus so it only shows one screenful at a time

# Zephyr

alias zl 'zlocate'

alias z 'zwrite'

alias zn 'znol -l | zwrite $user &' #sends a zephyr to you with a znol listing

alias zlcn 'zwrite -c long-class-name' #shortens a long command

alias wm 'echo "Zephyr White Magic"; z -i white-magic'

# Mail Stuff

alias nx 'next'

alias rnx 'rmm; next'

alias fop 'folder -pack' #packs your inbox

# Prompt stuff

alias cd 'set old=$cwd; chdir \!*;chdir .'

#cd saves the last directory you were in

alias back 'set back=$old;set old=$cwd;cd $back;unset back'

#returns you to the last directory you were in.

alias pmpt 'set prompt = "athena% "'

alias pmpt2 'set prompt = "\n<%h>%M:%d\n%%"'

#sets the prompt to display info about the number of commands run, what directory you are

#in and the machine you are logged into.

Appendix K: Sample ~/.Xresources

These are just a few examples, there are an almost limitless number of options available for ~/.Xresources.*foreground: white*background: blue*geometry: +0-0*geometry: +0-0*geometry: -0-0*geometry: +c+c*geometry: -0-0

zwgc*minTimeToLive: 1000

zwgc*reverseStack: on

XTerm*foreground: black

emacs*foreground: black

XTerm*background: blanchedalmond

emacs*background: blanchedalmond

XTerm*scrollBar: true

XTerm*saveLines: 500

XTerm*scrollTtyOutput: false

XTerm*scrollKey: true

XTerm*Scrollbar*thickness: 5

xclock*font: -*-helvetica-*-r-*-*-14-140-*-*-*-*-*-*

Console*autoUnmap: 30

Dash*logoutButton.window*geometry: 90x36-0-0

Dash*logoutButton*background: black

Dash*logoutButton*foreground: white

Dash*logoutDialog*background: black

Dash*logoutDialog*foreground: white

xcalc*Mode: rpn

console*foreground: black

console*background: blanchedalmond

Netscape*confirmExit: True #asks for exit confirmation #useful if you often hit exit when you meant close

Appendix L: Sample ~/.startup.X

xset b off #turn bell off

xsetroot -bitmap /mit/minidev/Public/Misc/dobbs.xbm #set background

xmh &

xss-button &

xclock &

xterm -geometry 80x40+0-0 &


Appendix M: Sample ~/.startup.tty

zctl unsub message busy-instance \*


znol -l


Appendix N: Sample ~/.environment

# anything beginning with # will be ignored


setenv MU_MSWORD frame #display mail Word documents in Frame #instead of as text

setenv MU_HTML html #display HTML mail in a web browser

#set skip_xlogout

set skip_sgi

set skip_xss

#set skip_dash

#set skip_initial_xterm

#set skip_X_startup

add games sipb graphics audio

Appendix O: Sample ~/.cshrc.mine

set rmstar #prompt before execution of "rm *"

set prompt = "my prompt "

alias dir "ls -l" #see appendix on aliases for more examples

set fignore = ( \~ )

set cdpath = (~)

source ~/.aliases #If you want a separate file for aliases this will

#source them.

Appendix P: Logging in Without Customizations

Logging in without customizations follows mostly the same process as logging in normally in an X session. Here is a quick flow chart of what happens where. The only difference between this and an X session is that no user configuration files are used in the course of the login procedures. To find out more about any steps along the way simply look back at the descriptions for the corresponding section in an X session login.

Xlogin gets tickets and calls /etc/athena/Xsession


| sets variable NOCALLS to signify a login without customizations

| Athena keymap modifications done as necessary

| sources /usr/athena/lib/init/xsession

| | echo "xsession: Running standard xsession with NO user

| | configuration files..."

| | setenv NOCALLS

| | Is this a verbose or quiet login? (NOCALLS assumes verbose)

| | sets "slow machine" values if needed

| | echo "Setting up environment..."

| | source /usr/athena/lib.init.cshrc

| | set some standard shell variables

| | | set standard environment variables

| | | set standard path

| | | set standard C shell variables

| | |______setup standard C shell aliases

| | windowmanager setup:

| | echo "Starting $WINDOW_MANAGER window manager..."

| | mwm (with /usr/athena/lib/X11/app-defaults/system.mwmrc

| | standard user start-up activities

| | Dash (with /usr/athena/lib/X11/app-defaults/Dash)

| | Xlogout, initial xterm, system start-ups (zwgc,

| | message of the day, check for mail and ping olc)

| | echo "Session initialization completed."

| |_______exec session_gate (waits for user to logout)

Destroys tickets, detaches your home directory.

Restarts Xlogin

Appendix Q: Sourcing a File

The command to source a file is:

source filename

athena% source ~/.cshrc.mine

When a file is sourced the information in that file usually consists of environment changes to the shell. Instead of starting a new shell with the modifications, sourcing a file allows the modifications to be made to an already existing shell. Sourcing a file executes a shell script within the current shell. Environment modifications take effect immediately in that shell.

When a file is sourced during session initialization the modifications carry through to all shells you use in that session. However, if you source a file in an xterm, the modifications to the environment take place only in the shell in that xterm. It does not effect any of your other shells.

Appendix R: Customizations Chart


Associated Dotfiles

Change Window Managers


Specify Locations/Colors of Zephyrs


A Screen Background


Set Aliases


Skip SGI window manager


Attach lockers


Skip Dash, logout button, initial xterm


Set default editor


Disable Printing header pages


Set custom prompt


Set screen location for programs


Set colors and fonts for programs


Set other program resources


Start a program upon login

~/.startup.X, ~/.environment , ~/.startup.tty and ~/.startup.sgi

Execute a coomand after logout is typed


Set size of core files


Put a scrollbar on your xterm


Appendix S: Quick Stations

Quickstations are workstations designed to be used for only a few minutes to check mail, print out a copy of a paper, or anything else that can be done in a couple of minutes. When logging into a quickstation, you may not want to use all of your customizations, especially if they take a long time to load. At the same time you may not want to login without customizations. In order to make this possible there is an environment variable $ATHENA_QUICK. $ATHENA_QUICK is set if you are logged into a quickstation, otherwise it is not set. It is possible to test wether or not you are logging into a quikstation or a regular workstation during session initialization. This allows you to choose what startup activities to use in a quickstation login versus a regular login.

if ($?ATHENA_QUICK) then









If you login to a quickstation commands one and two. will be used, if you login to any other kind of workstation commands A and B will be executed. Any commands to be run regardless of wether it is a quikstation should be left as they are in your dotfiles. Sections of customized dotfiles are included below.


#always do this:

set skip_x_startup

set skip_dash

set skip_xss

limit coredumpsize 0

if ($?ATHENA_QUICK) then # If this is a quick station do the following:

add consult sipb

setenv VISUAL emacs


else #If it's not a quick station do this:

add consult infoagents audio tcl graphics sipb calendar frame

setenv VISUAL ez

setenv WINDOW_MANAGER /mit/windowmanagers/$bindir/vtwm.gamma



#always do this:


xterm -geometry 80x40+0-0 &

if ($?ATHENA_QUICK) then # If this is a quick station do the following:

zctl unsub message help \*

zctl hide

else #If it's not a quick station do this:

netscape &


xclock &


This type of customization can not be made in your .Xresources file because that information is loaded with the xrdb command. It can be used with almost any other user customizable files, although the most time saving customizations to make will be to avoid adding lockers you won't use during a quick login, don't start programs that take a long time to load, such as Netscape and consider using a windowmanager that will take less time to load (especially if you have made a lot of customizations to your windowmanager). Setting aliases and variables take a relatively short time and will not make as much difference in your session initialization time as starting programs and adding lockers.

MIT Information Systems Comments and feedback to