Computer Laboratory

Initialisation files and configuration


New users in the Computer Lab are given a minimal set of startup files to get them started. The purpose of this page is to assist users who wish to configure their environment beyond that minimal set. First a warning: the main problem with allowing users to configure their environment is that it can make it rather difficult for the System Administration team to help in particular cases - some combination of your configuration settings could result in bizarre problems which might be impossible to diagnose without exactly duplicating your entire environment, which is obviously not easy. Thus the more you change your environment from the rather basic default the more you are on your own as far as assistance is concerned. So if that is the case why are we providing a set of pages to help you to do the very thing that makes our lives more difficult? Because we have noticed that the most common way that people configure their environments is by copying configuration files from other people. If you do this, and make no effort to understand the configuration file, then you will be extremely lucky if you get away without some unwanted side effects. With luck if we provide a place which tells people how to do it properly fewer people will get it wrong.

Logging in

The following describes in some detail the sequence of events when you login directly to a desktop machine, i.e. a machine in front of which you are physically present, as opposed to a remote login. It applies to both SUSE and Fedora Core (version 5 or later) machines.

When the machine is booted among many other things a "Display Manager" will be started. A Display Manager is a graphical login interface for computers using Unix-like operating systems. After performing a few configuration tasks it presents a login box against some pretty graphical background (you get a different one depending on whether the machine is running SUSE or Fedora) and it then sits there and waits for someone to log in.

There are three possible Display Managers:

  • XDM - the X display manager
  • GDM - the GNOME replacement for xdm
  • KDM - the K Desktop Environment (KDE) replacement for xdm

Which you get depends on configuration settings, but the default is GDM (regardless of whether you actually decide to run GNOME, KDE, or something else). In practice all the Display Managers are similar and use many of the same configuration files.

The Display Manager presents a login dialog box at which you can type your username and password. Somewhere on the screen but most likely at the bottom left will be Session Type (SUSE) or Session (Fedora). Clicking on these will bring up a list of the Window Managers and Desktop Environments which have already been installed on that particular machine, as well as other possibilities such as "Last" (whatever was last selected), "Default", and "Failsafe_Terminal" (see Recovering from mistakes). Simply select the one you want, and type in your username and password. Obviously, you get "Default" if you don't bother to select one yourself.

See Window Managers/Desktop Environments for more detail on these, or if you wish to use a Window Manager or Desktop Environment which is not on the list.

What happens next depends on which you select - the following assumes the machine is running GDM (the default) and you select the KDE Desktop Environment - very similar things happen with KDM, XDM, or a different Desktop Environment/Window Manager.

Once the user logging in has been authenticated (i.e. you've typed in a valid password and are allowed into the machine in question), GDM runs the startup script /etc/gdm/Init/Default as root to do a few initialisation tasks and then the session script /etc/gdm/Xsession (which is actually /etc/X11/xinit/Xsession) is run as the user logging in. This scripts starts (indirectly, via other scripts) startkde, which starts the kdeinit master process. The kdeinit master process is used to start all other KDE processes.

One of the things kdeinit starts is the ksmserver session manager process, see Session management. The session manager determines the lifetime of the session - when this process exits, the user is logged out. The session manager starts a stored session if one exists. If this stored session starts an xterm process then any shell startup files (i.e. .profile, .bashrc, possibly others) you have will be read and executed.

Session management

Desktop Environments include the concept of "session management", which means that when you log out of a session the nature, size and position of open windows is stored, and when you next log in the environment will attempt to open the same windows in the same places.

On startup the session manager launches auto-start applications and restores applications from the previous session. Sessions are stored in a configuration file which contains references to application-specific state information. For example, the KDE session manager saves them in files in your home directory in the subdirectory .kde/share/config/session. The saved sessions are simply text files with descriptions of the applications, and the properties of their windows.

It is fairly easy to build up a large number of miscellaneous windows using session management, so it is a good idea to close as much as you can before you logout. Some of the Desktop Environments allow you to configure precisely what their session managers restarts, see for example Configuration of XFce4.

Shell startup files, .profile and .bashrc

As mentioned above, the session manager may start up an xterm process - possibly with the -ls flag. This option indicates that the shell that is started in the xterm window will be a login shell. bash is the shell used by all lab members. Shells behave in one of two ways - as a login shell, or as an ordinary interactive shell. Normal behaviour is to have one xterm with a login shell and to spawn other xterm windows from that which will run ordinary interactive shells. The set of startup files used is slightly different in the two cases.

When bash is invoked as a login shell it first reads and executes commands from the file /etc/profile, if that file exists. This initialises a few environment variables, and calls a set of small initialisation scripts from the directory /etc/profile.d, which will vary depending on the software loaded on the machine (for example, if KDE is loaded there will be one called

After reading that file, it looks for ~/.bash_profile or ~/.bash_login or ~/.profile, in that order, and reads and executes commands from the first one that exists and is readable. (The --noprofile option could be used when the shell is started to inhibit this behaviour.)

When an interactive shell that is not a login shell is started, bash reads and executes commands from ~/.bashrc, if that file exists. (This may be inhibited by using the --norc option. The --rcfile file option will force bash to read and execute commands from file instead of ~/.bashrc).

Thus, by default, the file ~/.bashrc is not read automatically when a login shell is started. For this reason it is usual behaviour to add a section to ~/.profile (or ~/.bash_profile or ~/.bash_login) to read and execute it, so that you get uniform behaviour on both login shells and normal interactive shells.

If it exists, the individual login shell cleanup file, ~/.bash_logout, is executed when a login shell exits.

The equivalent file to ~/.bash_profile for the C shell (or tcsh) is ~/.login - it is not used by bash.


New arrivals at the Computer lab are given a ~/.profile file. Longer serving members may predate this policy decision and will have had to come up with their own - a copy of the standard file now given to new arrivals is here: sample .profile file.

The standard .profile starts with these comments:

# If you customise this file then please modify the first line or delete
# all the comments at the head of this file to avoid confusion if you have
# problems and ask for help.
# This file is commented to allow you to easily tailor your own environment.
# However, it should also provide sufficient functionality for those who do
# not wish to do so.
So the comments within the file should allow you to make sense of it and alter it if you wish.

export is a builtin shell command which ensures that the supplied names and their settings are marked for automatic export to the environment of subsequently executed commands. Thus .profile should contain export statements for all of the declared names, they can conveniently be listed all on one line at the end of the file, for example:

(As an aside, typing export -p will list all of the names that are exported in a shell.)

Typical items in a .profile file are settings for various defaults where there is a choice, e.g.

will ensure that your default printer on any print jobs (at least within this and any child xterms) are sent to the printer ash.

It is usually where you would add items to your search PATH, a colon-separated list of directories to search for commands if you do not give the full pathname, thus:


You can set a value for the prompt (the primary prompt, there are others used in other circumstances):

        PS1="$HOST\$ "
which will just give you the name of the machine you are logged into followed by a $, or
        PS1="$HOST:\W$ "
which will give you the name of the machine you are logged into followed by the name of the current working directory, followed by a $. There are many more possibilities here, see the PROMPTING section of the bash man page.

As mentioned above, it is also common to add a section to ~/.profile to read and execute (also known as sourcing) .bashrc as it is not otherwise sourced in login shells:

        if [ -f $HOME/.bashrc ]; then source ~/.bashrc; fi


This file is read and executed by bash whenever you start up an ordinary interactive shell.

It can be used to declare aliases or shell functions. Aliases are strings which are substituted for other words when used as commands - see the ALIASES section of the bash man page. Shell functions store a sequence of commands under a given name - see the FUNCTIONS section of the bash man page. The semantics of aliases are somewhat more restrictive (and confusing) than that of shell functions - aliases cannot take arguments for example.

An example shell function - if you always wish to use rm in interactive mode so that it requests confirmation before removing anything:

          /bin/rm -i $*;
The body of the function is the list of commands between { and }. This list is executed whenever its name is specified as the name of a simple command. The exit status of a function is the exit status of the last command executed in the body. The difference between a shell function and a separate shell script is that a shell function is executed in the context of the current shell, no new process is created to interpret them.

Alternatively, this is the equivalent alias:

        alias rm='/bin/rm -i'
The following is a cute trick which can be placed in your ~/.bashrc file to insert the name of the current working directory into the title bar of the xterm window:
        if [ $TERM = "xterm" ]
           # write current directory to xterm title 
           #   Escape sequence is: ESC]2;textC-G
           # and host name to icon
           #   Escape sequence is: ESC]1;textC-G
             if [ $A = "~$PWD" ] ; 
             then A="S:${PWD#$S}";
                  if [ $A = "S:$PWD" ] ;
                  then A=$PWD; fi;
             echo -n "^[]2;${HOST%%.*}: $A^G^[]1;${HOST%%.*}^G"'
           # enable application keypad setting.
           # Escape sequence is: ESC=
           echo -n "^[="
(Note that ^[ and ^G in the above are the single characters ctrl-[ and ctrl-G respectively, not two characters. Because of this it is better to download the file from here: sample .bashrc file rather than trying to type it in from this page.)

Resources: the .Xresources file

Resources in this context are adjustable parameters of an application which control such properties as window size, colour, fonts etc. If you have a file called .Xresources in your home directory it will be read as part of the logging in process (technically, by the Xsession script, see above). See Configuration of X resources for details of the sorts of things you can use it for.

Other "dot" files: .xsession, .xsession-errors, .Xclients, .xprofile, .xdmrc, .xinitrc, .xserverrc, .Xdefaults

You may have a large collection of other X windows "dot" files in your home directory which you have inherited from a past life somewhere else, or copied from someone else (a very bad habit...). Most of them will be unnecessary and will not be used given the way that we do things here, some may be positively harmful.

It is actually quite difficult to say which of these will be used and which will not as there is such enormous variability in the software that is installed on our Linux machines ! The following documents the usual situation:

Some dot files which are no longer needed:

  • .xprofile was intended to configure the shell that runs X system applications for you. By default the Desktop Environments do not use this anymore.
  • .xdmrc was meant to be used to start up applications (aka "clients") you always wanted to run when you used an X display. The concept of Session management has rendered this redundant and it is not used with the usual set of Desktop Environments.

Some dot files which may be considered dangerous and used with caution, if at all:

  • .xsession Launch a "session", i.e. an environment (or Window Manager). Under the combination of Display Manager and Desktop Environments (or Window Managers) that are usually used by Fedora Core 5 (and later) and SUSE, this file is not looked at at all. Thus its presence or absence makes no difference. Technically, it will be looked at if there are no Desktop Environment startup files present, but there almost always are. However, under earlier Fedora Core/Redhat versions the presence of a .xsession file would cause the system xsession file to be ignored, and as this was the major file used to set up displays this could be extremely dangerous - essentially anything could happen. As such the presence of this file has always been strongly discouraged. So - at present it will usually do no harm, but it has in the past and may again in the future.
  • .Xclients As per .xsession. Technically, it will be looked at if there are no Desktop Environment startup files present, and if there is no .xsession file. It is meant to be used for the same purpose as .xdmrc, i.e. starting clients, and hence redundant if you have a session manager.

Some dot files which have never been useful:

  • .xinitrc Used for the same purpose as .xdmrc or .Xclients. This relates to another method of starting an X session using xinit and startx (or xstart) which we do not use here. Its presence should do no harm, but it may be a source of confusion so you are advised to remove it.
  • .Xdefaults Used for the same purpose as .Xresources. As with .xinitrc, not used here.
  • .xserverrc Used to choose between Xservers if there are multiple posibilities. As with .xinitrc, not usually used here - however this one might be used if you use the Xfce4 Desktop environment, and if half a dozen other configuration files are not present (Confusing ... ?).

And lastly:

  • .xsession-errors This is created for you by the Display Manager - any errors recorded by the Display Manager are redirected to this file.

Recovering from mistakes

The Failsafe Terminal is an environment with a single window which does not start the X server and does not source any of the usual "dot" configuration files (such as .profile) in your home directory. It is intended as a way in when everything else is going wrong - for example if you have made a faulty modification to one of your configuration files which results in login failure. Select Failsafe_Terminal as the session at the login window and you will be presented with a single window. You can then use a non-graphical text editor (vi or emacs -nw) to fix the fault.