Operating System Information --> Unix Information --> General Usage Topics --> UNIX: What Are All These Dotfiles In My TerpConnect Account For? -->

UNIX: What Are All These Dotfiles In My TerpConnect Account For?

This page is based on Dotfiles (AC-16) from MIT. It has been modified to reflect the TerpConnect computer system environment. These files should not be removed from your account unless you know what you are doing.

Customizing Your Session

Overview

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 TerpConnect 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 dotfile 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.

z:~: cd
z:~: ls -a
.               .history           .rnlast          .xsession
..              .hushlogin         .rnsoft          .xsession-errors
.Xauthority     .kermrc            .ssh             Mail
.addressbook    .login             .startup.X       News
.cshrc          .logout            .startup.tty     mail
.dashmenurc     .newsrc            .tin             welcome
.emacs          .oldnewsrc         .twm.menus       
.environment    .path              .twmrc
.fullcircle     .pinerc            .xinitrc
.fvwm2rc        .reqrc             .xserverrc

This document covers:

• what happens during X (window login) and terminal (tty) login sessions,
• what dotfiles are used to achieve specific tasks
• some common customizations that can be made
• trouble shooting dotfiles
• dotfiles created by programs or to customize programs

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. The 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.

You enter your username and password.

Xlogin gets Kerberos tickets and the following files are called/used in this sequence

• ~/.xsession
• ~/.xsession-> ~/.xinitrc- .xsession is a soft link to ~/.xinitrc
• /local/lib/init/xinitrc
  • /etc/glue/hostinfo/userinfo.tcsh
  • ~/.cshrc
    • /local/lib/init/cshrc
      • /local/lib/init/environment.tcsh
        • ~/.environment if it exists
        • ~/.path if it exists
      • ~/.cshrc.mine if it exists
      • ~/.aliases if it exists
    • xrdb - merge /local/lib/init/Xdefaults
    • xrdb -merge ~/.Xdefaults if it exists
    • Window manager(FWVM2) is called using
      • ~/.fwvm2rc (if it exists)
      • /local/lib/init/fvwm2rc otherwise
    • ~/.startup.X if it exists
    • /usr/local/scripts/glueannounce
    • runs /usr/local/bin/dash
      • which references ~/.dashmenurc
        • /local/lib/init/dashmenu.setup
        • ~/.dashmenu.setup if it exists
        • /local/lib/init/dashmenu.root
        • /local/lib/init/dashmenu.logins
        • /local/lib/init/dashmenu.tap
        • ~/.dashmenu.lastword if it exists
    • /usr/local/bin/session_gate -logout

Destroy your Kerberos tickets, detach your home directory. The Kerberos system authenticates individual users in a network environment.

Xlogin restarts

Initialization Files

The following sections provides detailed descriptions about the files and programs associated with session initialization. Later sections will cover user modifications that can be made to your account and terminal style sessions.

Xlogin

Xlogin is the program that is running on a SUN workstation that is not in use. Xlogin is the program where you enter your username and password.

Xlogin provides many login functions. 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 ~/.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.

~/.xsession

This file is located in your home directory. ~/.xsession and is a soft link to ~/.xinitrc. ~/.xinitrc verifies that /local/lib/init/xinitrc exists, then sources it. During logout procedures /local/lib/init/logout destroys the Kerberos tickets and prepares for the next user to login. Then Xlogin regains control.

/local/lib/init/xinitrc

This file controls most of the login sequence as follows:

1. /local/lib/init/xinitrc 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/local/lib/init/.Xdefaults and ~/.Xdefaults files which are covered below.
5. Then a windowmanager is started. The default windowmanager is FVWM2 , but it is possible to select another windowmanager.
6. Then /local/lib/init/xinitrc starts a selection of programs, all of which can be avoided through alterations to the .environment file.
   • Dash: The menu bar on the top of the screen.
   • Initial Xterm: A large xterm window.
   • X Start-up:zwgc (zephyr), motd (sends a zephyr announcing closings and other info), mail (checks for new mail).
7. The .startup.X file is sourced and files that are to be run at start-up are executed.
8. Finally the xinitrc 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 Xlogin.

~/.hushlogin

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 help you find where problems occur during login. This makes it much easier to fix any mistakes you might make.

~/.cshrc

This file simply calls the initialization file /local/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 /local/lib/skel/.cshrc

It is a bad idea to modify your ~/.cshrc file as you will not get updates made to the system-wide file at a later date. You should use the ~/.path,~/.aliases, ~/.environment and ~/.cshrc.mine files to modify settings and make customizations. Changing the ~/.cshrc file is not encouraged or supported.

/local/lib/init/cshrc

This file is called by the ~/.cshrc. The /local/lib/init/cshrc is located in a central place so it can be updated for system changes.

This file sources a system-wide cshrc file, which:

The cshrc file sets the following shell variables:

Then the following environment variables are set:

Sources ~/.environment to set user specified environment variables

Sources ~/.path to set a user specified path

The following aliases are set your convenience:

If you have changed your .cshrc file and need a new copy of the file, at the prompt type:
newdefaults

Finally your .cshrc.mine is sourced to load user specified customizations and control is returned to /local/lib/init/xinitrc .

~/.environment

The ~/.environment file is a user created files that is used to set shell variables that control the session, and environment variables. A different windowmanager can be selected or standard start-up activities skipped. Printer options can be customized and default editor selections should be set here. All customizations made in this file are done only once a session and should be appropriate for both window and tty sessions. For more information go to Appendix N

~/.path

The ~/.path file is a user created file that should be used if changes to the default path are desired. The ~/.path contains a list of directory names (the command search path) where the shell knows to look for commands. The order of the directories determines where the shell will for the commands first. The only time ~/.path file is needed is if other directories are going to be put before the default TerpConnect path.

~/.cshrc.mine

This is a user created file where custom variables for the c-shell are set, aliases are created and other customizations specified. 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). Examples of these kinds of settings are " set skip_sgi "," set skip_dash &quot. For more information go to Appendix O.

~/.Xdefaults

The xsession file runs xrdb (Xserver resource database utility) on /local/lib/init/Xdefaults and ~/Xdefaults if the file exists in your home directory. This loads the preferences for X applications. ~/.Xdefaults can be used to change colors, specify locations, fonts, and other application specific settings. Xdefaults are stored in a database, not as variables. This is another user created file and is not created by default when you get your account. For more information go to Appendix K.

~/.startup.X

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 (a program that provides a graphical user interface to the Message Handling System) 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 and xmhare are programs that will not exit without user interaction. This means your session initialization will not finish and logging out may be difficult. For more information go to Appendix L.

~/.logout

This file is sourced by the /local/lib/init/xinitrc after logout is typed. ~/.logout can be used to run programs or scripts just before the session is over. Other ways of logging out go to Appendix G.

Common Customizations:

Do NOT make changes to ~/.logout ~/.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.

The files below are designed to be user modified and some of the customizations that can be made are mentioned below. This sections 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. There is also a chart in Appendix R that lists common customizations and what dotfiles you use to make those changes.

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

pico ~/.dotfile

z:~: pico ~/.cshrc.mine

~/.path

As mentioned above you can set your own 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 make your own path. The default path is listed by the variable $glue_path To view what is currently in $glue_path or $path:

z:~: echo $glue_path.

z:~: echo $path

An example of what could show:
/homes/userid/sun4bin /homes/userid/bin /usr/local/scripts /usr/local/bin /usr/sbin /usr/bin /opt/SUNWspro/bin /usr/ccs/bin /usr/ccs/lib /usr/ucb /usr/afsws/bin /afs/glue/software/lpcr/bin .

You can set your path by the following command at the prompt or in your ~/.path file. If you set your path in a shell (xterm), the path is only reset for that shell (and that session). Changes made in ~/.path are permanent although the changes do not take effect until the next time you login or source your ~/.path.

set path = ( $glue_path ~/fred/pub .)

The dot suggests that the system looks in the current directory last, this avoids you creating an already existing system command file name. An example would be rm (for removing files ). Finally the system looks in the your public directory. The variable $bindir is set earlier in your session initialization.

It is important to remember to include $glue_path when you are setting your own path. If you do not you may have trouble using many standard programs.

If you wish to simply add more directories to your path it is easier to use your ~/.environment file to add the directories in the order you want them in your path. You only need to use a ~/.path file if you wish to specify a path with a different beginning than the TerpConnect default.

~/.environment

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:

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 and ~/.path. If what you want to run depends on these files being sourced the command should be put in both ~/.path and ~/.cshrc.

~/.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. It is also 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, and when you next login ~/.cshrc will source ~/.aliases or you can type source ~/.aliases to have it take immediate effect.

To customize the prompt on your xterm:

set prompt = "New Prompt"

z:~: set prompt = "My Prompt"

~/.Xdefaults

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

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

Capitalization is very important as all Xdefaults are case sensitive. Some capitalization in Xdefaults is not intuitive.

You can find information about the Xdefaults for most programs by reading the manual ( shorten to man ) provided by the system. Just typing: man program_name

Example:

z:~: man zwgc

There are a few common types of customizations you can make in your Xdefault 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).

zwgc.style.b5*geometry: +c+c
zwgc.style.login*geometry: +0-0
zwgc.style.logout*geometry: +0-0
zwgc.style.message.personal*geometry: -0-0
zwgc.style.message.foo*geometry: -0+0
zwgc.style.message.bar*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:

program_name*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 Xdefaults, another popular customization is to change the color of programs on your screen:

This will cause your xterm to have blue text and a background color of black. 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 available colors type at the prompt:

/usr/X/lib/rgb.txt on Solaris 5.10

There are a nearly infinite number of options with Xdefaults, 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-*-*-*-*-*-*

~/.startup.X

This file should contain whatever commands you would type at your prompt, one per line, for the programs to be started upon initialization. Some common programs to start are xclock (pops up a clock on your X-Win session), xload (shows the load running currently on your computer), and xmh (Message Handling system). Note that starting anything time consuming/computationally intensive, such as Firefox 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. Use an ampersand (&).

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

Example:
z:~:firefox &

~/.logout.mine

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

cd /$USER/home

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

cat .plan

The ~/.logout.mine file commands must apply to both X and terminal sessions. Also, do not use commands that require user input since the ~/.logout.mine file is run from the console window in X sessions and there is no method for user input.

~/.hushlogin

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:

z:~: 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 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

Appendices

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 shell is tcsh, c-shell, but there are other shells that exist that you can use instead

Appendix B: Tcsh C shell Special Characters

Tcsh is the default TerpConnect 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.

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 variableid=value

set prompt="z:~:"

Environment variables are set by:

setenv variablename value

setenv TERM VT100

To display them:

z:~: echo $prompt

z:~: 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:

z:~: set

z:~: 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

Fvwm2 is the default windowmanager, but twm and mwmis 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.

for more information on how to change window managers, go to http://www.helpdesk.umd.edu/systems/wam/connectivity/labs/1233/
However bear in mind that fvwm2 is the only supported window manager.

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.

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_hush after you've already logged in will not cause any noticeable change. 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

z:~: source ~/.cshrc.mine

Aliases can be tested individually at the prompt

z:~: 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:

z:~: set prompt="my new prompt "

z:~: 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.

z:~: echo $prompt

z:~: 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 ~/.Xdefaults 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 ~/.Xdefaults

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, call the Office of Information Technology (OIT) Help Desk.

Once you have logged in 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 use appendix I (see below). 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.

• Type logout in any xterm window
• Use dash choose the special menu and the logout option.
• Click on the root window, background area on the screen, to get a menu. Depending on the type machine you are logged into you may be able to select logout or a new xterm window. If you get the xterm window simply type logout at the z:~: prompt.
• If none of these options are available or fail due to changes you made, DO NOT REBOOT THE WORKSTATION.
  call the OIT Help Desk.

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. Zephyr on TerpConnect has a section on its dotfiles and other documents contain information on other program specific dotfiles.

You can learn a lot about X defaults by reading the X manual page and the manual pages for programs you wish to customize. To view the manual page for 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

z:~: man zwgc

z:~: man ls

Appendix I: Default Dotfiles

A new set of UNIX and X-windows defaults have been developed by the TerpConnect staff. A default is an action that a computer performs if no alternatives are specified. The system defaults can be used as a starting point for developing a personal set of defaults.

The new defaults are designed to allow the underlying computer system to be modified and upgraded without forcing users to modify any of their customized defaults, or to have to repeatedly re-install the defaults.

The new defaults modify the behavior of five different aspects of the computer system: terminal settings, the UNIX shell, X-windows programs, the X-windows manager and logout processing.

These defaults were new to TerpConnect, and may be different than what you are used to using. Please report any problems that you have with them. If they are not to your liking, this handout will tell you what files you need to change. If you had made changes to the old defaults, this document will tell you how to change the new defaults to incorporate your changes.

How to install the new defaults

All TerpConnect users are urged to switch to the new defaults. This is done by typing the command:

newdefaults

If you get the message Command not found, try typing the command:

/usr/local/scripts/newdefaults

If this does not work, contact the system staff.

The newdefaults command copies files into your home directory. If a file with the same name as a new defaults file already exists, the old existing file is renamed. This gives you a backup copy. The new name of the file consists of the file's old name concatenated with the date. For example, if the file .Xdefaults exists in your home directory and today's date is September 23, 1991, the newdefaults command will rename .Xdefaults to .Xdefaults-91-09-23, and put a new copy of .Xdefaults in its place.

The newdefaults command can be run whenever you want to get a fresh copy of the defaults. This can be useful if you make a change to a start-up file that results in undesirable behavior.

The New Default Files:

Here is a brief description of each file that is copied into your home directory:

Files that are used to affect the shell:

.cshrc the commands in this file are performed each time a shell is started. This file contains commands that configures your shell. Do not edit this file.

.environment this file contains customized environment variable settings in C-shell syntax. The newdefaults command gives you a .environment file with a couple of lines as an example. This file can be deleted if you do not wish to change any environment variables.

.path this file contains your customized search path. The specified path will be used in place of the default path. The file provided by the command newdefaults gives you the same path as the system default; it is provided to give you an example of how the file should look. This file can be deleted if you do not wish to change your search path.

.cshrc.mine contains commands that are performed each time a shell is started. This is the file that you use to modify shell variables. This file can be deleted if you do not wish to change any variables.

.aliases contains C-shell command aliases. You can use it to add your own aliases, or re-define system aliases. This file can be deleted if you do not wish to change any aliases. Files that are used to affect terminal settings:

. login commands in this file are performed each time you login to a computer using a workstation's console or network connection. This file contains commands that configures your terminal. Do not edit this file.

.startup.tty contains the customized terminal settings which are performed when logging in from a terminal. The .startup.tty can be deleted if you do not wish to change any of the terminal settings.

Files that are used to affect X-windows:

.xinitrc commands in this file are performed when X-windows is started. It calls a system-wide program that performs various system functions. These functions can be overridden by using environment variables in your . environment file. Do not edit this file.

. startup .X contains commands that are performed when X-windows is started. It is called by the system file that is called by .xinitrc. It contains the commands that put up the xterms, the clock and the xbiff that you see when you log in and start X-windows. Modify this file if you wish to modify the set of tools to be run.

.Xdefaults contains values of X-windows resources. These affect how X-windows applications look and act. You can override an application's default resources by adding lines to this file. The newdefaults command gives you a .Xdefaults file with a couple of lines as an example. This file can be deleted if you do not wish to change any resources.

.xserverrc Do not modify this file.

.xsession a link to your .xinitrc file. Do not modify this file.

Files that are used to affect logout processing:

. logout the commands in this file are performed when you log off of the system console or remote login. Do not edit this file.

. logout . mine this file contains commands that you want to have performed when you logout. This file can be deleted if you do not wish to add any special commands to be performed when you log out.

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 fx'firefox &'

# 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

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

#returns you to the last directory you were in.

alias pmpt 'set prompt = "z:~: "'

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 ~/.Xdefaults

These are just a few examples, there are an almost limitless number of options available for ~/.Xdefaults.

zwgc.style.random*foreground: white

zwgc.style.random*background: blue

zwgc.style.login*geometry: +0-0

zwgc.style.logout*geometry: +0-0

zwgc.style.random*geometry: -0-0

zwgc.style.message.urgent*geometry: +c+c

zwgc.style.message.personal*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

XScreensaver*geometry: 20x20+0+0

XScreensaver*lockCommand: zaway

XScreensaver*float.bitmap: /joeuser/Bitmap/Smiley

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

Appendix L: Sample ~/.startup.X

xset b off #turn bell off

xsetroot -bitmap ~/pictures/dobbs.xbm #set background

xmh &

xclock &

xterm -geometry 80x40+0-0 &

fortune

Appendix M: Sample ~/.startup.tty

zctl unsub message busy-instance \*

inc

znol -l

fortune

Appendix N: Sample ~/.environment

# anything beginning with # will be ignored

setenv WINDOW_MANAGER twm

#set skip_xlogout

#set skip_dash

#set skip_initial_xterm

#set skip_X_startup

Appendix O: Sample ~/.cshrc.mine

set prompt = "my prompt "

set lineedit #enable use of line editing in the shell

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 Q: Sourcing a File

The command to source a file is:

source filename

z:~: 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

Copyright Notice: Copyright © 1999 by Massachusetts Institute of Technology (MIT).

Permission to use, copy, modify, and distribute IS documentation for any purpose and without fee is hereby granted, provided that the above copyright notice appear in all copies and that both that copyright notice and this permission notice appear in supporting documentation, and that the name of MIT not be used in advertising or publicity pertaining to distribution of the software without specific, written prior permission. MIT makes no representations about the suitability or merchantability of the documentation (or its associated software) for any purpose. It is provided "as is" without express or implied warranty.

Trademark Notices: Athena ®, Hesiod ®, Moira ®, OLC ®, and Discuss ® are registered trademarks of the Massachusetts Institute of Technology (MIT).

Project Athena, Athena Dashboard, Athena MUSE, Kerberos, X Window System, and Zephyr are trademarks of MIT. No commercial use of these trademarks may be made without prior written permission of MIT.

All other product names are trademarks of their respective companies.