![[ TABLE OF CONTENTS ]](../gx/indexnew.gif)
![[ FRONT PAGE ]](../gx/homenew.gif)
So, you've got X Windows working on your system, you've set your system to automatically start xdm by setting the default run state to 5 and now you want to customize your personal windows session by having certain applications start automatically after you log in.
At work, I like to log out of my system every evening before I go home so that others may log in when I'm not there. It doesn't happen often, but I don't want someone coming into my office and using a window logged in as me. [You never know when someone gets curious and starts wandering through my saved mail messages.] The problem is, I have certain applications that I want brought up automatically, like my list of things to do and my calendar program.
In this article, I'm going to explain an X Windows session, how it is started and what you can do to customize it. It will show you how to automatically start the window manager of your choice, have applications start automatically and customize colors and fonts to your liking. Since X Windows is pretty much identical on all platforms, much of what I am going to explain can be used on other platforms that use X Windows other than just XFree86 on Linux. As a matter of fact, I will make some comparisons between the version of XFree86 that comes with Red Hat 5.x and what comes with Silicon Graphics IRIX®. You may note that the files I discuss on both systems have the same name but are usually just in different directories.
I realize that other articles have been written about X Windows configuration, for example Jay Ts' fine article in the December issue entitled ``X Window System Administration.'' X Windows is an extremely versatile windowing environment and, because of this, can be very complex. For this reason, I believe it will require many articles that might overlap but each will provide information from a different perspective. This article is intended to be from a user's perspective, rather than from an administrator's.
To start off with and to keep my article from becoming a book in itself, this article is written with the following assumptions:
When the X server is started automatically via xdm, the user is presented with a login screen. When a user successfully logs in via this screen, xdm starts the ``user session''. This session is a shell script which, when it terminates, ends the user's session and xdm resets the X server and returns to the login screen.
Prior to starting a session, xdm runs a small startup script with root privileges to perform any user initialization that may be required. Currently, this file, /etc/X11/xdm/GiveConsole, changes the ownership of /dev/console to that of the user so messages sent there can be displayed on a window in the user's environment.
In like manner, when the session ends, xdm runs another small exit script with root privileges to clean up anything that might have been set up by the startup script. Currently, this script, /etc/X11/xdm/TakeConsole, changes the ownership of /dev/console back to root.
Note that these two files are /var/X11/xdm/GiveConsole and /var/X11/xdm/TakeConsole on the SGI.
The step of interest to this article is the actual starting of the user session itself. Here, xdm starts a subprocess running the script /etc/X11/xdm/Xsession (/var/X11/xdm/Xsession on SGI) and waits for it to exit. When it does, xdm processes the exit script and returns to the login screen. This session script is run with the user's privileges.
A resource has been set for xdm which causes the parameter ``failsafe'' to be passed to the user session if the user uses the F1 key rather than the Enter key to complete his/her login. This can be very useful if the user makes a mistake in his or her customized session script which makes it impossible to log in. How this feature is taken advantage of is discussed below. It should be noted that I found this resource defined for both Linux and SGI and is used in an identical manner on both.
The /etc/X11/xdm/Xsession file provided by Red Hat is quite simple, especially when compared to the /var/X11/xdm/Xsession file provided with the SGI. This file is a standard Bourne shell script which performs all the user startup and initialization that the system administrator wants done for all users.
As described above, if the user logs in and pressed F1 rather than the Enter key, the parameter ``failsafe'' is passed to the session file. The first thing the /etc/X11/xdm/Xsession file does is check if this parameter exists and, if it does, exec's an xterm. This bypasses all other initialization and provides the user with a terminal window to work with. Notice that this is a good method of logging in if the user has done something to his/her personal session file that otherwise prevents logging in.
For those that don't understand the function of exec, this is a builtin command provided by all the standard shell programs. It causes the current running shell to be replaced by the exec'd program. Thus, the current running shell never returns from an exec (unless the program referenced fails to start for some reason) and the parent process is not aware of any change in the child process. The exec'd program retains the process ID of the shell and, when it terminates, it is as if the shell terminated and the user session ends.
Presuming ``failsafe'' is not a parameter passed to Xsession, the script continues by redirecting stderr to an error file. If it can write to it, this file will be .xsession-errors in the user's home directory. If the session can't write to the user's home directory or this file is write protected for some reason, the script will attempt to use /tmp/xses-$USER, where $USER is the user's login name.
This error file is useful for determining problems during the user's session. Any errors generated by applications that are started (including the window manager or applications started by the window manager) will be sent to this file. If the user has problems starting a user session after logging in, he/she can perform a ``failsafe'' login (as described above) and look at this file. The error messages may be of some help in determining the problem.
Finally, the standard Xsession file transfers control to one of a set of shell scripts, depending on their existence and if they are executable. It does this with the exec command which means that, whichever program is run, it replaces the Xsession process and becomes the new user session. The shell scripts are:
1. $HOME/.xsession 2. $HOME/.Xclients 3. /etc/X11/xinit/XclientsSome interesting notes about this compared to the script used on an SGI computer. SGI does not require the scripts to be executable but will run /bin/sh against them if they aren``t. Also, SGI only looks for $HOME/.xsession. If this file doesn't exist, the system Xsession file sets up the default user environment provided by SGI. Red Hat chose to break the default user session into two steps, since the standard installation will provide /etc/X11/xinit/Xclients.
If none of the three files above exist or are executable, then the user``s .Xresources file is loaded (if it exists) and the program xsm is exec'd. xsm is one of the many window managers provided with Red Hat Linux.
As you may have guessed from the above explanation of the system's Xsession file, the user can create his/her own shell script which will be processed as the user session. This is a very powerful capability and provides each user the ability to do whatever processing they want each time they log in via the X login. In this script, the user can start various applications, set root window resources, set one-time environment variables, change default keyboard definitions and select a window manager.
The easiest way to set up your own personal Xsession file is to copy the system /etc/X11/xinit/Xclients file into your home directory as .xsession or .Xclients (what, in the future, I will refer to as the user's Xsession file) and then edit it as desired. I'm not going to step through the contents of the /etc/X11/xinit/Xclients file, you can do this on your own. I'm going to just explain some of the things one might want to do.
One important thing is to load desired resources into the root window. This is usually done with the following commands:
resources=$HOME/.Xresources if [ -f "$resources" ]; then /usr/bin/X11/xrdb -load "$resources" fiAnother thing that the user may wish to do is set the root window background to something different. This is done with the /usr/bin/X11/xsetroot command. For example, I have my background defined as follows:
Note that this command can also be used to set the default cursor and cursor color for the root window, a two-tone plaid pattern for the background or an X bitmap to be used as a pattern.
Also, the command /usr/bin/X11/xset can be used to set the desired bell volume, key click, DPMS (energy saving) features and mouse parameters. This command can also set autorepeat and screensaver parameters.
If you want to define special keys, you can run /usr/bin/X11/xmodmap from this script. For example, I like to be able to access the full ISO 8859-1 character set and insert internationalized characters in my documents. Also, Linux likes to define <Shft>F1 to be F11 and <Shft>F2 to be F12. Since my keyboard has an F11 and F12, I prefer these keys to be set to F13 and F14 respectively. To handle this, I have defined $HOME/.xmodmaprc to contain the following:
keycode 113 = Multi_key keysym F1 = F1 F13 keysym F2 = F2 F14 keysym F3 = F3 F15 ... keysym F10 = F10 F22 keycode 95 = F11 F23 keycode 96 = F12 F24Then, in my $HOME/.xsession file I have the following:
if [ -r $HOME/.xmodmaprc ]; then /usr/bin/X11/xmodmap $HOME/.xmodmaprc fiFinally, the most important step is running a window manager. Red Hat likes to run fvwm because it can be set up to look a lot like Windows 95®. Since I use SGI computers a lot, I prefer Motif (which costs money and doesn't come with Linux normally). There is also xsm and twm available. You might want to read the man pages for each to determine which window manager you prefer.
If it is desired, the user can exec the window manager as the last thing in the Xsession file. This will mean that the user has to end the window manager to end their session and return to the login screen. I prefer to run the window manager as a background process and exec an xterm as the last thing. This way, when I exit the xterm session, the user session will end and the login screen will be brought up. Note that the window manager and any window applications will be terminated because the X display will be closed. Any non-window applications started as a background process will not be terminated automatically and could continue after the user's session ends.
I start the Motif window manager as follows:
/usr/bin/X11/mwmI start the final xterm with:
exec nxterm -geometry 80x50+10+10 -lsThis creates a version of the xterm that supports color. It will be 80 characters wide and display 50 lines. The window will be positioned in the upper left corner of the screen (at pixel position 10x10). The last option forces nxterm to run the shell as a login shell.
From within the user's Xsession file, you can run a number of xterms, xclock or whatever, all of which will start automatically when you login. Be sure to specify a geometry (with the -geometry option) to get each application positioned on the screen where you want it.
Also, remember to run the applications in the background (by terminating the line with ``&'') otherwise, the user Xsession file will wait until that application terminates before continuing.
Here I want to discuss some more interesting and important tricks that can be done from the user's Xsession file.
All window managers can execute programs from a pulldown menu. Sometimes these programs need special environment variables defined prior to their execution (for example, Netscape may need SOCKS_NS to be defined). Since the user's environment variables are not usually set until a shell is started, the window manager and any programs started from the window manager will not have the user's environment defined. Trying to set them in $HOME/.cshrc, $HOME/.profile or $HOME/.login won't do any good.
One trick is to define these environment variables in the user's Xsession file. It is necessary to set these environment variables before you start the window manager.
Another trick that I like to do is define XUSERFILESEARCHPATH in my user Xsession file. Most applications look for and use a application resource file, usually found in /usr/lib/X11/app-defaults. For example, Netscape uses the file /usr/lib/X11/app-defaults/Netscape for its application resource settings. If you want to change any of these settings for your personal environment, you can copy this file into your home directory and modify it. Next time you run Netscape, it will find the one in your home directory first and use it.
I have found my home directory cluttered with application resource files and wanted to put them into my own private app-defaults directory. I did this by creating the directory and copying all the resource files into it. Then, I set XUSERFILESEARCHPATH to the following in my user Xsession file:
/home/carlson/app-defaults/%N:/usr/lib/X11/%L/app-defaults/%N:/usr/lib/X11/app-defaults/%NThis makes the application search in /home/carlson/app-defaults for application resource files before going to the default locations under /usr/lib/X11.
One last trick is for those of you that have multiple computers all running X servers. Here at home, I have an SGI O2 and my Linux machine. When I log in remotely to my O2, I want to be able to run X applications and have them use the display on my Linux box. In order to do this, I need to run xhost each time I log in to my Linux box to allow remote logins to access the X server.
As part of my user Xsession file, I have the following line:
/usr/bin/X11/xhost +moonlightThis sets the X server on my Linux box to allow access from moonlight, the name of my O2.
I hope you have found this information useful and interesting. I've tried to show you how to create your own user Xsession file to start applications, set a special environment and run your own window manager. I'm sure you can come up with many more ideas.
One useful tool that I wrote, based on a similar application provided with SGI, is userenv. This application creates a login shell as a child and has it print its environment. This environment is collected and then printed to stdout in a form that can be executed to create the same environment by a shell.
In my user Xsession file, I have the following line:
eval `userenv`This computes my user environment and echos it in a form that the shell can execute the output to create the same environment. The eval command causes the output to be processed by the shell.
You are welcome to a copy of the source for this program from my web site, http://members.home.net/cwcarlson/files/utilities.tar.gz.
I am running Red Hat 5.1 but it appears that it hasn't changed significantly for a few years. Also, I find the configuration almost identical with other Unix platforms such as Silicon Graphics IRIX®. The only differences appear to be in what directory files are maintained.)