1. Manuals
  2. Tumbleweed
  3. xsession
  4. xsession(1x)

Scroll to navigation

XSESSION(1) General Commands Manual XSESSION(1)

NAME

xsession - session manager for the X Window System

SYNOPSIS

xsession [-toolkitoption ...] [-console] [-cpp] [-defaultWM ...] [-D...] [-m4] [-keep] [-notify] [-remote] [-sounds] [-split] [-startup] [-version] [-help]

DESCRIPTION

The xsession program is a session manager. It is normally executed by your ~/.xinitrc (or ~/.xsession) script and controls your X Window session. As soon as it is started, xsession launches a window manager and some applications of your choice. At anytime during your session, you may switch to another window manager or execute some other applications from the xsession menus. You may also lock your screen using an independent locker application and redirect to the xsession window the messages usually sent to /dev/console.

One useful feature of xsession is the preprocessing of window managers' configuration files. When a window manager is launched, its startup file can be filtered through m4(1) or cpp(1). Some macros are defined (such as the host name, screen size and so on) that will help you customize your menus and screen layout. One advantage of this feature is that several window managers can share the same startup file. For example, you can (and we do) use the same file for mwm(1) (Motif), twm(1), ctwm(1) and vtwm(1). Some lines are protected by a test on the ``WM_NAME'' macro, but the other lines are common. This saves a lot of time if you want to maintain the same menu structure for the four of them. You can also use ``include'' statements in your file.

The best way to execute xsession is to include it in your ~/.xinitrc (or ~/.xsession) file, as the last client. The xinit(1) manual page says that ``the last long-lived program started [...] should be left in the foreground so that the script won't exit''. You will find a similar statement in the xdm(1) manual page. This last program should be xsession. As a matter of fact, this may even be the only program executed in your startup file, because xsession itself provides a way to launch other applications. When started, xsession will look in your home directory and execute a file named .X11Startup, if found. This shell script is used to start your client programs.

OPTIONS

XSession accepts all of the standard X Toolkit command line options (such as -iconic, -geometry and so on; see X(1)). The following additional arguments are supported. Note that because the standard X Toolkit method is used to retrieve X resources, most of the command line options are only another way to set the value of some resources. These options always take precedence over their corresponding resources.

When -console is set, xsession tries to redirect the console output messages to its window. This feature should work on most systems, but it may be necessary that xsession is ``setuid'' to root.
Specifies the (short) name of the default window manager to launch. See the ``Menu customization'' section below for details. The easiest way to choose your default window manager is by using X resources in your ~/.Xdefaults file (or the file you read with xrdb(1)). The default value is ``TWM''.
Sets the ``keepTmpFile'' resource to ``true''. This option is used mainly for debugging purposes.
When a message is printed in the xsession window and -notify is set, the icon name of the application has `` *'' appended, so that it is evident even when the application is iconified. When the application is de-iconified, the icon name will be restored to its initial value. The -notify option is set by default.
Specifies which preprocessor must be used. Only two values may be used: either ``m4'' or ``cpp'' according as you want to use m4(1) or cpp(1). The default value is ``m4''.
If you use this option, xsession will not print any messages when an application or window manager is started. The warning messages (e.g. ``configuration file not found'') will not be displayed either.
You should set this option if you run xsession on a remote host (e.g. if your ~/.xinitrc or ~/.xsession file tests if you are on a oldish machine and, if so, executes xsession on a more powerful host in a remote shell). XSession must then execute a special exit code to work around an unwanted feature in rsh(1) that prevents it from exiting if there is one or more children of xsession alive. This exit code shuts down the socket associated with the remote connection.
Activates (or disables) the sounds. The sounds will only be available if xsession was compiled with SOUNDS defined. The sounds are activated by default if SOUNDS was defined, they are disabled otherwise.
When -split and -console are set, the output messages of the programs and the ones related to the console are shown in separate windows. The -split option is set by default, but will be silently ignored if the ``console'' option is not used.
If -startup is set, then the user's .X11Startup file is executed by xsession at startup. You may want to turn this option off for debugging purposes or if you don't have a .X11Startup file. The -startup option is set by default.

Note: if you use a ``+'' instead of a ``-'' in the boolean options above, then the effect will be reversed (e.g. +startup is the same as -nostartup).

There is no X resource equivalent for the following command line options:

This defines a symbol for the preprocessor that is run on the window managers' configuration files. All instances of symbol in the configuration files will be replaced by the NULL string (if xsession was compiled with USE_M4 defined) or 1 (if xsession was compiled with USE_CPP).
This defines a symbol for the preprocessor that is run on the window managers' configuration files. All instances of symbol in the configuration files will be replaced by value.
These options are equivalent to -preprocessor cpp and -preprocessor m4, respectively.
Guess what?
Prints the current version number and exits.

X DEFAULTS

This program uses mainly the Text, Paned, Box, MenuButton and SimpleMenu Athena widgets. Look in the Athena Widget Set documentation for controlling them. See also the ``Application resources'' section in this manual page.

WIDGETS

In order to specify resources, it is useful to know the hierarchy of the widgets which compose xsession. In the notation below, indentation indicates hierarchical structure. The widget class name is given first, followed by the widget instance name.

	XSession  xsession
		Paned  top_pane
			Box  menu_box
				MenuButton  session_button
					SimpleMenu  menu
						SmeBSB  lock_menu_item
						SmeBSB  quit_menu_item
				MenuButton  wm_button
					SimpleMenu  menu
						SmeBSB  <window manager's short name>_menu_item
						.
						. (one for each window manager)
						.
				MenuButton  app_button
					SimpleMenu  menu
						SmeBSB  <application's short name>_menu_item
						.
						. (one for each application)
						.
				MenuButton  misc_button
					SimpleMenu  menu
						SmeBSB  clear_menu_item
						SmeBSB  clear2_menu_item
			Text  ascii_text
			Text  ascii_text2

The <window manager's short name> and <application's short name> represent the short name of the program (a window manager or another application). For example, if you have ``TWM'' in your ``Window Managers'' menu, you will have a SmeBSB instance named ``TWM_menu_item''.

APPLICATION RESOURCES

XSession has the following application-specific resources which allow customizations unique to xsession. Some of these resources have command line equivalents which may be used to override them.

Any of these options may also be specified on the command line by using the X Toolkit Intrinsics resource specification mechanism. For example, to run xsession using xlock(1) to lock the screen,

	% xsession -xrm '*lockCommand:xlock -mode random'
Either ``true'' or ``false''. When ``true'', this resource directs xsession to ring the bell if the message printed in its window contains one or more bell character(s). This may happen if the output from one application launched from the menu contains such characters (e.g. in an error message). Default value: ``false''.
This resource is a comma-separated list which gives the (short) names of the applications to be shown in the ``Applications'' menu. See the ``Menu customization'' section below for details about names and short names of the applications. The default value should have been customized for your site during the installation of xsession. The names inside this resource are used as <application_name> to build the following resource names:
Each of these resources is a string that gives the full application name, followed by a comma and the command to execute the application. See the ``Menu Customization'' section below for details about building these resources.
console (Class Console)
Either ``true'' or ``false''. If this resource is ``true'', xsession tries to redirect the console output messages to its window. This feature should work on most systems, but it may be necessary that xsession is ``setuid'' to root. Default value: ``false''.
This resource contains the short name of the default window manager to launch. See the ``Menu customization'' section below for details. Default value: ``TWM''.
Either ``true'' or ``false''. If this resource is ``true'', xsession will not delete the temporary files created for the preprocessor and the window manager. This only makes sense if you use a preprocessor (such as m4(1) or cpp(1)) to filter the window manager's configuration file. This option is used mainly for debugging purposes. Default value: ``false''.
This resource contains the command to execute when the user selects the ``Lock'' entry in the ``Session'' menu. The string can contain space characters in order to add some arguments to the command. Default value: ``xscreensaver-command -lock''.
Either ``true'' or ``false''. When this resource is ``true'', the content of the /etc/motd file is printed in the xsession window at startup. Default value: ``true''.
Either ``true'' or ``false''. When a message is printed in the xsession window and this resource is ``true'', the icon name of the application has `` *'' appended, so that it is evident even when the application is iconified. When the application is de-iconified, the icon name will be restored to its initial value. Default value: ``true''.
Specifies which preprocessor must be used. Only two values may be used, either ``m4'' or ``cpp'', according as you want to use m4(1) or cpp(1). Default value: ``m4''.
quiet (Class Quiet)
Either ``true'' or ``false''. If this resource is ``true'', xsession will not print any messages when an application or window manager is started. The warning messages (e.g. ``configuration file not found'') will not be displayed either. Default value: ``false''.
remote (Class Remote)
Either ``true'' or ``false''. The usual way to change this value is by using a command line option, not an X resource. Default value: ``false''.
Either ``true'' or ``false''. When a message is printed in the xsession window and this resource is ``true'', the bell is rung so that the user is warned even if the window is not visible. Default value: ``false''.
Either ``true'' or ``false''. If this resource is ``false'', then the sounds are disabled. The sounds will only be available if xsession was compiled with SOUNDS defined. Default value: ``true'' if SOUNDS was defined, else ``false''.
Either ``true'' or ``false''. If both this resource and the console resource are ``true'', the normal output messages of the programs and the ones related to the console are shown in separate windows. Default value: ``true''.
Either ``true'' or ``false''. If this resource is ``true'', then the user's .X11Startup file is executed by xsession at startup. You may want to turn this option off for debugging purposes or if you don't have a .X11Startup file. Default value: ``true''.
This resource is a comma-separated list which gives the (short) names of the window managers to be shown in the ``Window Managers'' menu. See the ``Menu customization'' section below for details about names and short names of the window managers. The default value should have been customized for your site during the installation of xsession. The names inside this resource are used as <window_manager_name> to build the following resource names:
Each of these resources is a comma-separated list that defines the properties of a window manager. The first field is the full name of the window manager. The second field is the command to execute in order to run this window manager. The third field (optional) gives the name of the configuration file that should be filtered through m4(1) or cpp(1) to produce the actual window manager's startup file. The fourth and fifth fields (optional) are used to explain to xsession how the window manager can read an arbitrary file as configuration file; this can be done using command line arguments or an environment string. See the ``Menu customization'' section below for details about building these resources.

If xsession was compiled with the SOUNDS symbol defined, the following additional X resources are available. See the ``Sounds'' section below for additional information about using sounds in xsession.

Name of the sound file to play when xsession starts. Default value: ``none''.
Name of the sound file to play when xsession ends. Default value: ``none''.
Name of the sound file to play when a window manager starts. Default value: ``none''.
Name of the sound file to play when a window manager ends. Default value: ``none''.
Name of the sound file to play when an application starts. Default value: ``none''.
Name of the sound file to play when an application ends. Default value: ``none''.
Name of the sound file to play when the screen locker starts. Default value: ``none''.
Name of the sound file to play when a message is printed in the main window. Default value: ``none''.

PREPROCESSING OF WINDOW MANAGERS FILES

One of the most powerful features of xsession is its ability to filter the window managers' setup files through a preprocessor. This is useful if you work on several machines which don't necessarily have the same characteristics, or if you wish to share a common configuration file between several window managers. You can use m4(1) or cpp(1) directives (e.g. file inclusion directives) and pre-defined symbols to customize your environment at runtime. XSession uses either m4(1) or cpp(1) to pre-process the setup files, according to the value of the preprocessor resource.

When xsession starts a new window manager, it creates a temporary file for the preprocessor. This file contains all symbols that will be defined and then includes the original window manager's configuration file. The preprocessor will parse that file and send its output to another temporary file. This latter file will be the actual window manager's configuration file. In order to achieve this, xsession should have a way to force the window manager into using another input file. This is usually done with a command line parameter for the window manager (such a ``-f name'') or with an environment variable. If a window manager provides no way for doing this, you won't be able to use the preprocessing features for it. See ``Menu Customization'' below for details.

The following symbols are defined (most of these definitions were borrowed from the ctwm(1) manual page):

The version number of xsession.
The process number of xsession. You may use this pid to send a SIGHUP signal and terminate the session from one of the window manager's menus.
This variable is set to the name of the machine that is running the X server.
The machine that is running the clients (i.e. the window manager and all other applications).
The canonical hostname running the clients (i.e. a fully-qualified version of CLIENTHOST).
The machine type of CLIENTHOST (e.g. ``sun4m'', ``mips'', ``i486'', ...).
The name of the user running the program. Gotten from the environment.
The user's home directory. Gotten from the environment.
The X major protocol version. As seen by ProtocolVersion(3).
The X minor protocol revision. As seen by ProtocolRevision(3).
The vendor of your X server. For example: ``MIT X Consortium''.
The release number of your X server. For MIT X11R5, this is ``5''.
The width of your display in pixels.
The height of your display in pixels.
The X resolution of your display in pixels per meter.
The Y resolution of your display in pixels per meter.
The number of bit planes your display supports in the default root window.
The number of significant bits in an RGB color. (log base 2 of the number of distinct colors that can be created. This is often different from the number of colors that can be displayed at once.)
The visual class of your display. It returns one of ``StaticGray'', ``GrayScale'', ``StaticColor'', ``PseudoColor'', ``TrueColor'', ``DirectColor'', or, if it cannot determine what you have, ``NonStandard''.
This variable is just a wrapper around the CLASS definition. It returns ``Yes'' on StaticColor, PseudoColor, TrueColor and DirectColor displays. On the other displays, it is undefined if you use cpp(1), and it returns ``No'' if you use m4(1).
The name of the current window manager. This is useful for protecting parts of one shared setup file: you may use the same file for several window managers and protect some lines if they are understood by only one of them.
Same as WM_NAME. For compatibility with ctwm(1) configuration files.

Here is a short summary of the useful directives of m4(1) and cpp(1). Please refer to their own manual pages for any additional information.

Warning: when using m4, xsession automatically inserts the following m4 directive in the temporary file:

	changequote([,])
This will use the square brackets as string delimiters, instead of the default quote and backquote characters, which are probably already used in your file. Don't duplicate this directive in your file, because m4 doesn't like that...
With m4, use define(symbol, value).
With cpp, use #define symbol value.
With m4, use include(file) or sinclude(file). The sinclude directive is similar to include, except that it does not complain if the file is inaccessible.
With cpp, use #include "file".
With m4, use eval(expression).
There is no equivalent for cpp.
With m4, use ifdef([symbol], result1, result2), where the third argument is optional. Note that the square brackets are used to quote the symbol. If the symbol is defined, this expression returns result1, else it returns result2.
With cpp, use #ifdef symbol ... #else ... #endif, where the #else ... part is optional. Each directive should be on a line by itself. If symbol is defined, then the lines between #ifdef and #else will be output. If not, then the lines between #else and #endif will be output.

With m4, ifelse(expr1, expr2, result1, ...) does the following: if expr1 and expr2 are the same string, then the result of the ifelse is result1. If not, and if there are more than four arguments, the process is repeated with arguments 4, 5, 6 and so on. Otherwise, the value is either the last string not used by the above process, or NULL if it is not present.
Some versions of cpp allow a similar structure with #if, but most versions do not have any equivalent.

Although m4 is less intuitive than cpp, it has more features. This is why our preferences go to m4 for preprocessing the window managers' files. See also the ``Examples'' section below, it shows some parts of configuration files to be preprocessed by m4.

MENU CUSTOMIZATION

The ``Window Managers'' and ``Applications'' menus may (and should) be customized for your site using X resources. These menus are built from the X resources using a two-stage process: first, the list of items is read from a resource, then the definition of each item is searched in the resource database.

The wmNames resource string is a comma-separated list that gives the (short) names of the window managers that will be listed in the menu. These names should be short and contain characters from the set {`A'-`Z', `a'-`z', `0'-`9', `_', `-'} (no space character). Each of these names is then used to create a new resource name, using the prefix wm_, that holds the complete description of the window manager.

This also applies to the applications, with the appNames and app_... resources.

For a given window manager, the wm_<window_manager's_short_name> resource must be built as follows. It is a comma-separated string made of five fields (which are not allowed to contain any comma characters, of course):

•
The first field is mandatory and denotes the full name of the window manager. It may contain space characters.
•
The second field is mandatory and denotes the command to execute in order to run this window manager. This field may contain space characters in order to add some arguments to the command.
•
The third field is optional and specifies the name of the configuration file which must be preprocessed by xsession for this window manager. This field must contain one and only one occurence of ``%s'' which will be replaced by ``m4'' or ``cpp'' according to the preprocessor that is used. Remember that only the preprocessed file is used by the window manager, not the original and usual one (see ``Preprocessing of window managers files'' above).
•
The fourth and fifth fields are optional. The aim of these fields is to explain to xsession how this window manager can read an arbitrary file instead of its default configuration file. All well-behaved window managers should be able to do that! Some of them use an environment variable, while others need a command line option. If a command line option is needed, it should be placed in the fourth field of the string; this field must contain one and only one occurence of ``%s'' to specify where the filename should be inserted in the arguments list. If an environment variable is needed, the fifth field should be defined as ``VARIABLE=VALUE'', where ``VARIABLE'' denotes the name of the environment variable to be used, and ``VALUE'' denotes the value to be assigned to the variable; ``VALUE'' must contain one and only one occurence of ``%s'' to specify where the filename should be inserted into the variable.
For most window managers, it should be possible to use one of these two fields. If both are undefined or if there isn't any occurence of ``%s'' in them, then the preprocessed file cannot be given to the window manager by xsession; in that case, you will lose the preprocessing feature for this window manager, because it will always take its default configuration file, without any preprocessing applied on it.

For a given application, the app_<application's_short_name> must be built as follows. It is a comma-separated string made of two fields. The two fields are mandatory:

•
The first field denotes the full name of the application. It may contain space characters.
•
The second field specifies the command to execute in order to run this application. This field may contain space characters in order to add some arguments to the command.

In order to add a new window manager (respectively a new application) into the xsession menus, you have to insert its short name in the wmNames (respectively appNames) resource, and to create a new resource named wm_<window_manager's_short_name> (respectively app_<application's_short_name>) built according to the rules above.

EXAMPLES

If you want to add a new application to the ``Applications'' menu (e.g. xmosaic), you need to do two things: first, add the name of this application in the appNames list (this is the name that will be shown in the menu). The appNames resource in your ~/.Xdefaults file should now look like this: 
XSession*appNames: XTerm, Emacs, XEdit, XMan, XMosaic
Then, add a new resource to define the application. This string contains the application's full name followed by the command that xsession will execute: 
XSession*app_XMosaic: XMosaic (WWW browser), xmosaic -dil
The next time you run xsession, your ``Applications'' menu will have a new entry for xmosaic.
You can use the same file for several window managers. For example, you can have a common file called .wmrc.m4 that is used by ctwm(1), twm(1) and vtwm(1). If some lines in this file are specific to one of these window managers, you can perform a test on WM_NAME to prevent other window managers from seeing them. For instance, here is an excerpt from the ``Colors'' section of our .wmrc.m4 file: 
Color
{
	DefaultBackground  	"blue"
	DefaultForeground  	"yellow"
ifelse(WM_NAME, ctwm, [
	MapWindowBackground	"white"
	MapWindowForeground	"black"
], WM_NAME, vtwm, [
	DoorBackground     	"orange"
	DoorForeground     	"blue"
	VirtualBackground  	"LightSteelBlue"
])
}
You can also use the preprocessor (m4, here) to define a symbol that will be used later. For example, if you can define a ``FULLSCREEN'' variable that will give the correct geometry for a window that should cover the whole screen. Here is another excerpt from a .wmrc.m4 file: 
define(FULLSCREEN, translit(WIDTH*eval(HEIGHT - 30)+0+0, *, x))
define(SHOWIMAGE, [xv -quit -rmode 1])
menu "Applications"
{
	"Applications"	f.title
	"XMan"       	f.exec "xman -notopbox -bothshown -pagesize FULLSCREEN &"
	"Backgrounds"	f.title
	"Stupid logo"	f.exec "SHOWIMAGE winlogo.gif &"
}

See also the examples directory in the xsession distribution for longer examples.

SOUNDS

XSession can use the rplay library if it is installed on your system. If xsession was compiled with SOUNDS defined, then it will play a sound when some event occurs. For example, you may configure xsession to play ``Creaky-1.au'' when you start it, and ``goodbye.au'' when you quit. You only need to add the following lines to your ~/.Xdefaults file (or the file you read with xrdb(1)):

	XSession*soundStart:	Creaky-1.au
	XSession*soundEnd:  	goodbye.au

Here is how this works: when the selected event occurs, xsession will send a request to the rplayd server running on CLIENTHOST, asking it to play a sound. The rplayd server will take care of what is needed to find the sound file and play it.

You will find the rplay library and lots of sound files on the following FTP site: sounds.sdsu.edu (130.191.224.4). You will also find the library on ftp2.montefiore.ulg.ac.be and ftp.x.org.

COLORS

Like some other X applications, xsession provides another set of resources if you want to use it on a color display. You only need to include the following lines in your ~/.Xdefaults file (or the file you read with xrdb(1)):

	#ifdef COLOR
	*customization:    -color
	#endif

This will cause xsession to pick up the colors in the application-defaults color customization file (XSession-color) instead of the standard applications-defaults customization file (XSession).

ENVIRONMENT

To get the default host and display number. If this variable is not defined in the environment and the -display command line option is used instead, xsession adds this variable to its environment.
To get the name of the user's home directory. If this variable is defined, xsession changes the current directory to the one specified in this variable.
If set, temporary files will be created in this directory. Otherwise, temporary files will be created in /usr/tmp.
To get the name of a resource file that overrides the global resources stored in the RESOURCE_MANAGER property.

FILES

/usr/lib/X11/app-defaults/XSession
specifies required resources for standard displays
/usr/lib/X11/app-defaults/XSession-color
specifies resources for color displays
~/.xinitrc
the best way to launch xsession
~/.xsession
another good way to launch xsession
~/.X11Startup
startup file executed by xsession
/etc/motd
message-of-the-day
/usr/tmp/xs_WM<...>
preprocessed startup files created by xsession

SEE ALSO

X(1), xinit(1), xdm(1), xrdb(1), m4(1), cpp(1), twm(1), ctwm(1), mwm(1), xscreensaver(1), xlock(1), xconsole(1), Athena Widget Set, X Toolkit Intrinsics.

BUGS

The program may crash if you put more than one ``%s'' in the third, fourth or fifth field of a wm_<window_manager's_short_name> resource or if you give another incorrect format string.

All symbols defined for the preprocessor are blindly replaced in the window managers' startup files, and this may cause some problems. For instance, if you use the variable ``$HOME'' in one file, the preprocessor will replace the symbol ``HOME'' by its actual value, and your window manager will see a lost ``$'' before the path name. Solution: remove the ``$'' sign.

If used from xsession, mwm(1) (Motif) must be customized in such a way that it does not prompt the user if it receives a KILL signal. Indeed, when you decide to switch to another window manager, xsession sends a KILL signal to the current window manager, waits until it ends, and starts the new one. If, thanks to the prompt, the user cancels the order sent by xsession, the window manager will not end and xsession will wait forever. For mwm(1), the showFeedback (class ShowFeedback) resource must be changed from its default value (``all'') to something that does not include ``kill''. For example, you can use ``behavior move placement quit resize restart'' as the value of this resource.

Please report other bugs to the authors at the following E-mail addresses. Thanks. We would rather get criticisms than no comments at all!

AUTHORS

Raphael Quinet	<quinet@montefiore.ulg.ac.be>


              	<quinet@stud.montefiore.ulg.ac.be>
Alain Nissen  	<nissen@montefiore.ulg.ac.be>


              	<nissen@stud.montefiore.ulg.ac.be>

COPYRIGHT

Copyright © 1993, 1994, Alain Nissen & Raphael Quinet, University of Liege, Belgium.

The X Consortium, and any party obtaining a copy of these files from the X Consortium, directly or indirectly, is granted, free of charge, a full and unrestricted irrevocable, world-wide, paid up, royalty-free, nonexclusive right and license to deal in this software and documentation files (the "Software"), including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons who receive copies from any such party to do so. This license includes without limitation a license to do the foregoing actions under any patents of the party supplying this software to the X Consortium.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM, THE AUTHORS OR THE UNIVERSITY OF LIEGE BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.

The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.

AVAILABILITY

The most recent released version of xsession is available for anonymous FTP from ftp.x.org (198.112.44.100) in the directory /contrib/applications. The latest version under development is available for anonymous FTP from ftp2.montefiore.ulg.ac.be (139.165.8.25) in the directory /pub/xsession.

6 June 1994 Version 1.1