409 lines
18 KiB
HTML
409 lines
18 KiB
HTML
<!--startcut ==========================================================-->
|
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
|
|
<HTML>
|
|
<HEAD>
|
|
<title>An xdm Session LG #43</title>
|
|
</HEAD>
|
|
<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#0000FF" VLINK="#0000AF"
|
|
ALINK="#FF0000">
|
|
<!--endcut ============================================================-->
|
|
|
|
<H4>
|
|
"Linux Gazette...<I>making Linux just a little more fun!</I>"
|
|
</H4>
|
|
|
|
<P> <HR> <P>
|
|
<!--===================================================================-->
|
|
|
|
<center>
|
|
<H1><font color="maroon">An xdm Session</font></H1>
|
|
<H4>By <a href="mailto:cwcarlson@home.com">Chris Carlson</a></H4>
|
|
[Revised to fix a few HTML tags. Originally published in issue #42.]
|
|
</center>
|
|
<P> <HR> <P>
|
|
|
|
<p>
|
|
So, you've got X Windows working on your system, you've
|
|
set your system to automatically start <i>xdm</i> 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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
To start off with and to keep my article from becoming a book in itself,
|
|
this article is written with the following assumptions:
|
|
<p>
|
|
<ol>
|
|
<li> That you are working with the default configuration of xdm as
|
|
it is installed by Red Hat (see <a href="#foot">Footnote</a>). This means that you haven't
|
|
changed any of the files found in /etc/X11/xdm. (Since I don't
|
|
have an installation of any of the other Linux vendor releases, I'm
|
|
presuming their default configuration is identical or similar enough
|
|
that it won't cause any problems.)
|
|
With this in mind, I will refer to filenames that are used and
|
|
referenced by xdm (and their contents) as specified in the installed
|
|
configuration file. It should be noted, however, that almost all of
|
|
these filenames can be changed by modifying /etc/X11/xdm/xdm-config
|
|
or by specifying a different configuration file on the command
|
|
line when starting xdm. (On the SGI, the configuration file is
|
|
/var/X11/xdm/xdm-config and I have seen some installations use
|
|
/usr/lib/X11/xdm/xdm-config.)
|
|
<li> That you have a basic understanding of the server/client concept
|
|
used by X Windows. i.e. The X server handles the display and keyboard
|
|
and runs as an application. User's applications are clients that
|
|
request services from the X server to display things and provide input.
|
|
<li> That you have some familiarity with X resources and how they
|
|
are used in the X environment.
|
|
</ol>
|
|
<p>
|
|
<h3>User Session Initialization and Termination</h3>
|
|
<p>
|
|
When the X server is started automatically via <i>xdm</i>, the user is
|
|
presented with a login screen. When a user successfully logs in via this
|
|
screen, <i>xdm</i> starts the ``user session''. This session is
|
|
a shell script which, when it terminates, ends the user's session
|
|
and <i>xdm</i> resets the X server and returns to the login screen.
|
|
<p>
|
|
Prior to starting a session, <i>xdm</i> 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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
Note that these two files are /var/X11/xdm/GiveConsole and
|
|
/var/X11/xdm/TakeConsole on the SGI.
|
|
<p>
|
|
The step of interest to this article is the actual starting of the user
|
|
session itself. Here, <i>xdm</i> 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, <i>xdm</i> processes the exit script and returns
|
|
to the login screen. This session script is run with the user's
|
|
privileges.
|
|
<p>
|
|
A resource has been set for <i>xdm</i> 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.
|
|
<p>
|
|
<h3>The Xsession File</h3>
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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:
|
|
<p>
|
|
<pre>
|
|
1. $HOME/.xsession
|
|
2. $HOME/.Xclients
|
|
3. /etc/X11/xinit/Xclients
|
|
</pre>
|
|
Some 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.
|
|
<p>
|
|
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
|
|
<i>xsm</i> is exec'd. <i>xsm</i> is one of the many window managers
|
|
provided with Red Hat Linux.
|
|
<p>
|
|
<h3>User Customized Xsession File</h3>
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
One important thing is to load desired resources into the root window.
|
|
This is usually done with the following commands:
|
|
<p>
|
|
<pre>
|
|
resources=$HOME/.Xresources
|
|
if [ -f "$resources" ]; then
|
|
/usr/bin/X11/xrdb -load "$resources"
|
|
fi
|
|
</pre>
|
|
Another thing that the user may wish to do is set the root
|
|
window background to something different. This is done with the
|
|
<i>/usr/bin/X11/xsetroot</i> command. For example, I have my background
|
|
defined as follows:
|
|
<p>
|
|
<pre>
|
|
/usr/bin/X11/xsetroot -solid DarkSeaGreen4
|
|
</pre>
|
|
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.
|
|
<p>
|
|
Also, the command <i>/usr/bin/X11/xset</i> 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.
|
|
<p>
|
|
If you want to define special keys, you can run <i>/usr/bin/X11/xmodmap</i>
|
|
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:
|
|
<p>
|
|
<pre>
|
|
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 F24
|
|
</pre>
|
|
Then, in my $HOME/.xsession file I have the following:
|
|
<p>
|
|
<pre>
|
|
if [ -r $HOME/.xmodmaprc ]; then
|
|
/usr/bin/X11/xmodmap $HOME/.xmodmaprc
|
|
fi
|
|
</pre>
|
|
Finally, the most important step is running a window manager.
|
|
Red Hat likes to run <i>fvwm</i> 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
|
|
<i>xsm</i> and <i>twm</i> available. You might want to read the man pages
|
|
for each to determine which window manager you prefer.
|
|
<p>
|
|
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.
|
|
<p>
|
|
I start the Motif window manager as follows:
|
|
<p>
|
|
<pre>
|
|
/usr/bin/X11/mwm
|
|
</pre>
|
|
I start the final xterm with:
|
|
<p>
|
|
<pre>
|
|
exec nxterm -geometry 80x50+10+10 -ls
|
|
</pre>
|
|
This 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.
|
|
<p>
|
|
>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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
<h3>Important Tricks</h3>
|
|
<p>
|
|
Here I want to discuss some more interesting and important tricks
|
|
that can be done from the user's Xsession file.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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.
|
|
<p>
|
|
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:
|
|
<p>
|
|
<pre>
|
|
/home/carlson/app-defaults/%N:/usr/lib/X11/%L/app-defaults/%N:/usr/lib/X11/app-defaults/%N
|
|
</pre>
|
|
This makes the application search in /home/carlson/app-defaults
|
|
for application resource files before going to the default locations
|
|
under /usr/lib/X11.
|
|
<p>
|
|
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 <i>xhost</i> each time I log in to my Linux box to allow
|
|
remote logins to access the X server.
|
|
<p>
|
|
As part of my user Xsession file, I have the following line:
|
|
<p>
|
|
<pre>
|
|
/usr/bin/X11/xhost +moonlight
|
|
</pre>
|
|
This sets the X server on my Linux box to allow access from
|
|
moonlight, the name of my O2.
|
|
<p>
|
|
<h3>Conclusion</h3>
|
|
<p>
|
|
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.
|
|
<p>
|
|
One useful tool that I wrote, based on a similar application provided
|
|
with SGI, is <i>userenv</i>. 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.
|
|
<p>
|
|
In my user Xsession file, I have the following line:
|
|
<p>
|
|
<pre>
|
|
eval `userenv`
|
|
</pre>
|
|
This computes my user environment and echos it in a form that
|
|
the shell can execute the output to create the same environment.
|
|
The <i>eval</i> command causes the output to be processed by the shell.
|
|
<p>
|
|
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.
|
|
<p>
|
|
<a name="foot"></a>
|
|
<h3>Footnote</h3>
|
|
<p>
|
|
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.)
|
|
<p>
|
|
<!--===================================================================-->
|
|
<P> <hr> <P>
|
|
<center><H5>Copyright © 1999, Chris Carlson <BR>
|
|
Published in Issue 43 of <i>Linux Gazette</i>, July 1999</H5></center>
|
|
|
|
<!--===================================================================-->
|
|
<!--startcut ==========================================================-->
|
|
<P> <hr> <P>
|
|
<A HREF="index.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
|
|
ALT="[ TABLE OF CONTENTS ]"></A>
|
|
<A HREF="../index.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
|
|
ALT="[ FRONT PAGE ]"></A>
|
|
<A HREF="bennet.html"><IMG SRC="../gx/back2.gif"
|
|
ALT=" Back "></A>
|
|
<A HREF="feinberg.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
|
|
<P> <hr> <P>
|
|
</BODY>
|
|
</HTML>
|
|
<!--endcut ============================================================-->
|