![[Return to Library]](BOOKSHELF.GIF)
![[TOC]](TOC.GIF)
![[PREV]](REW.GIF)
![[NEXT]](FF.GIF)
![[INDEX]](INDEX.GIF)
![[Help]](HELP.GIF)
X resources are defined for display aspects of the Digital UNIX operating
system itself as well as for all the X client applications that are part of
the operating system. X applications that are installed on top of the operating
system also have resource definitions. Resources characteristics include
color specifications for various elements in a window display, presence of
scroll bars for a window, location of windows on the desk top area, font used
for text, and width of window borders.
Resource definitions are used in all applications based on the X Window
System, such as xterm, Calendar, and even the X Display
Manager xdm. The Digital UNIX operating software provides default
resource definitions for the X Window System. Users can modify some resource
definitions to customize their workstation environment; for example, to set
the colors and positions of windows.
There are three ways to set resources:
Only a subset of resources can be set from the command line, but the
advantage of this method is that you do not need to edit any files to apply
the definitions. Section 3.2 discusses this
method.
The system administrator can use systemwide files to establish uniform
settings for small or large groups of users; or special individual settings. Section 3.3 discusses this method.
Programmers who are writing X Window System client applications include
resource definitions in their code so that they control the look and feel
of the application. Section 3.4 describes some utilities
that help users and programmers specify resource definitions.
Resource definitions for the Digital UNIX operating software clients
are located in the /usr/lib/X11/app-defaults/ClassName
files. These resources are used only by a client that runs on the
local host, even if the client appears on a remote X display.
These definitions are usually located in files in the user's home directory,
$HOME/ClassName.
If
several hosts share the home directory, the definitions in the directory will
also be shared by those same hosts.
Host-specific resource definitions are located in either the $HOME/.Xdefaults-hostname
file
or a file pointed to by the $XENVIRONMENT
variable. These definitions are only used by applications running
on the host system and are not specific to the display.
Some users use a resource database loaded by the X Server Resource Database
utility
(xrdb) to specify display-specific default
resource settings.
If no resource database exists for the user, the X server applies the
resource definitions in the $HOME/.Xdefaults
file.
Users can change some resource definitions by specifying the new resource
settings on the command line when they invoke the client application. Section 3.2 and the
It is important to be aware of which resource definitions take precedence
of other definitions; hence, the use of ascending numbers in the preceding
list. System definitions are overridden by user definitions, which are, in
turn, overridden by host-specific definition. A definition supplied through
a command-line flag overrides any existing definition for that resource. However,
only the 17 standard resources or resources for which the client application
has provided a command flag can be defined using command-line flags. Other
resources must be specified in definition files or by using the -xrm flag.
Note that host-specific and user-specific resource files do not necessarily
have to reside
in the user's home directory. There are several environment variables that
can be set to specify a search path for default files:
This environment variable is used to set the path for systemwide application-specific
resource definition files.
This environment variable is used in place of $HOME for application-specific
user resource definition files.
If this environment variable is defined and XUSERFILESEARCHPATH is not, the search path becomes:
$XAPPLRESDIR is replaced by the value of that environment
variable; $HOME is replaced by the user's home directory. If there
is no definition for $XAPPLRESDIR, the path is the user's home
directory:
The %L element resolves to a full-locale name if one exists; %l resolves to the language component element of the locale; %N resolves to the name of the file being searched for. If no file exists
in the locale or if no locale has been defined, the path collapses to the
next level.
To load resources using xrdb,
use either the -load flag (the default) or the -merge flag and specify
a new resource definition file. With the -load flag, all
previous resource definitions in the X server are deleted and replaced with
the new definitions in the specified file. If the new file does not contain
a definition for a resource that was defined previously, that resource definition
is either lost or reverts to a default. The -merge flag
allows you to change and add resource definitions without losing existing
ones that you do not modify in the new definition file that you specify with
the xrdb command.
Table 3-1 lists the standard command-line
flags and the resources they modify.
3.1 Resource Definition Overview
The term resources file
refers to characteristics
of X Window System applications or applications built on X Window System technology.
Resources values define all sorts of aspects of the X display on a workstation
and the
window applications that run
in the X Window System environment.
3.1.1 Setting Resources
System administrators can
set systemwide resources to provide a more uniform environment for the people
working at the workstations or X terminals for which they are responsible.
Programmers rely on resource specifications to create application windows,
dialog boxes, and menus as well as to establish a particular look and feel
for their applications' displays.
3.1.2 Resource Definition Precedence
Because of the variety
of methods for setting resources, there could be times when there are several
definitions for a particular resource. For X Window System environment resources,
the definitions are applied in the following order:
X(1X) reference page provide
information on the standard resources that can be set from the command line
for most applications. Client applications can create additional flags that
set resource definitions which are specific to the particular application.
$XAPPLRESDIR/%L/%N:$XAPPLRESDIR/%l/%N:$XAPPLRESDIR/%N:$HOME/%N
$HOME/%L/%N:HOME/%l/%N:$HOME/%N
3.1.3 Loading Resource Definitions
The X Window System
Administrator's Guide recommends that you use xrdb
to load resource definitions directly into the X
server. Using xrdb promotes consistency in the way applications
run. In addition, because xrdb runs the resource definition file
through a C preprocessor, you can further customize the environment by using #ifdef and #include commands in the resource definition files.
You can also use the -D (define symbol) and -U (undefine symbol) flags on the xrdb command line to set
up different environments on different hosts; so users can move among workstations
with different capabilities and maximize the special features on each one.
(See Section 3.4.4 for more information.)
3.2 Using Command-Line Flags
When you invoke
a client application on your workstation, you can use command line flags to
specify certain characteristics for the appearance, location, and features
of the window display.
There are a number of
standard flags that are used with X Toolkit or Motif Toolkit applications.
Not all such applications use all the standard resource flags, but many use
most of them. Programmers can also create application-specific flags so that
users can set other resources for those applications.
To modify an application resource definition, include the flag on the command line that invokes the application. Most flags require a parameter such as the name of a color, a file name, or a text string. The reference page for the command that invokes the application lists the appropriate flags and their parameters.
The following examples
show how
some of these standard flags are specified when an application is invoked:
Programmers need to understand resource definitions so they can use
them when they create their applications. System administrators use resource
definitions to set up a default working environment for the workstations they
maintain. End users can use resource definitions to customize their workstation
environment and even to customize some display characteristics of applications
they run.
This section explains the structure of resource definitions, gives examples
of how to create and modify the definitions, and describes the kinds of resource
definition files that you can edit to customize your environment.
object.subobject[.subobject...].attribute: value
The parameters have the following definitions:
Specifying the object, attribute, and value parameters is relatively straightforward. In general, the object parameter is the name of the client program. The resource attribute refers to the characteristic you want to modify, add, or delete. The
second column in Table 3-1 contains the names
of some resource attributes. The description gives you an idea of the kinds
of values you can specify such as a color name for foreground,
pixel coordinates for geometry, a font string for font,
and a locale for xnlLanguage.
Creating resource definitions can be a bit more complex if you have
to deal with subobjects. When you want a value to apply to an attribute
throughout the application, you can use an asterisk (*) to indicate all the subobjects. For example, if you want the background color to be light
blue for every dialog box, menu, message box, and so on in the AccessX client,
you could use the following resource definition:
This kind of definition is known as a loose binding because the value
applies to all appropriate widgets in the hierarchy.
If you want to have a dark-blue background only for the status boxes,
you would use the following resource definition:
This definition requires that you know every element in the widget hierarchy
from the main widget, accessx to the status box widgets. This
kind of definition has a tight binding; that is, each subwidget between the accessx widget and the statusbox widget is listed in order,
separated by periods.
To determine the elements in the widget hierarchy for an application,
you need to use the editres utility. This utility creates a display
of the hierarchy and also provides a way to test your resource definition.
See Section 3.4.1 and the
If your resource definition file will be run through the C language
preprocessor, you can use #ifdef and #endif constructs
to deal with definitions that are to be applied under certain circumstances.
For example, you might have color definitions that would only be applied
when you were working at a workstation with a color monitor.
The /usr/lib/X11/app-defaults
directory contains resource definition files for many of the window
client applications that are included with the Digital UNIX operating software.
These files are read-only, so users cannot edit the contents to change or
add resource definitions. However, you can use some of these definitions
as models for your own definitions in a resource file or as part of the command
line you issue to invoke the client. Note that many of these definitions specify
things that you would not want to customize, such as the alignment of the
buttons on the calculator application.
The files in the /usr/lib/X11/app-defaults directory do contain
some resource definitions that you might find useful as models for definitions
you create. For example, you could use the Clock-Color file to
get some ideas for color definitions.
More resource definitions files are located in your $HOME
directory. Some of these files can be specific to applications that you run.
For example, you could create a file called XTerm in your $HOME directory that would be read every time a new XTerm window was
created on the display. Any definitions for resources already defined in
the /usr/lib/X11/app-defaults/XTerm file would be overridden by
the definitions in your personal XTerm file.
Host-specific resource definition files customize your display
environment and are
read by all client applications running on your host. One such file is called $HOME/.Xdefaults.
You can
set colors for the display background and foreground as well as for various
elements of the windows that appear. You use this file to specify your default
window manager. If you usually work on a system with a color monitor, but
occasionally use a monochrome monitor, you can include color definitions in
your .Xdefaults file surrounded by #ifdef and #endif statements. These definitions will only be processed if the
COLOR C preprocessor symbol is defined. If you use dxsession,
the definitions in the .Xdefaults file will be loaded into the
X servers resource database. Otherwise, you can use the xrdb utility,
which automatically uses the C preprocessor to deal with such programming
constructs. Note that dxsession does not use the C preprocessor
to process the .Xdefaults file and dxsession only understands
a limited number of C preprocessor directives. You can use the xrdb -symbols command to see which symbols xrdb has defined.
In general, you will want to use xrdb
to load one or more resource definition files into
the X server's database. The xrdb utility is usually invoked by
a session script such as $HOME/.xsession. See Section 3.4.4
for more information on xrdb.
If you do not load the X server's resource database either by using xrdb or by using the Session Manager, each time an X application starts
up, it reads the .Xdefaults file and applies all relevant resource
definitions. The dxsession program processes the local
.Xdefaults
file and loads the resource
definitions into the X server's database.
The editres utility displays the widget hierarchy along with
the names and definitions of all the resources for a particular X client application.
This information enables a user or programmer to add, modify, or delete resource
definitions for the application. The editres utility can dynamically
apply the resource changes to the application. Thus, the user or programmer
can immediately see the results of the new definition and decide whether or
not to save the change, restore the original setting, or make another change.
The editres main window has four areas: Menu Bar, Panner,
Message Area, and Application Widget Tree display. You use the Menu Bar to
access the different editres features. The Panner provides an
intuitive method for scrolling through the Application Widget Tree display.
The display area shows the widget tree for the application specified through
the Get Widget Tree menu item.
The Show Resource Box menu item creates a pop-up window that contains
resource definitions for the widget that is currently selected in the Application
Widget Tree display.
You use the Set Resource pop-up window to enter a resource definition
for all the widgets currently selected in the Application Widget Tree display.
(You can use Tree menu commands to select more than one widget by specifying
such keywords as All, Children, Parents, Descendents, or Ancestors; or by
specifying a widget class.)
In most instances, you use the Resource Box to determine whether a resource
has been defined and what that definition is. You also use this box to add,
modify, or delete resource definitions and to indicate to which widgets these
changes apply. Once you have made your change, you use the Apply button to
see the effects of your change. Press the Save button to save the change
you have made. There is also a Save And Apply button, which performs both
operations at once.
Note that some client applications have hard-coded the attributes for
certain elements rather than use resource definitions. There is no way for editres to modify hard-coded attribute specifications.
You can use the -q flag with the xset command
to display the current settings for your workstation. To change a setting,
issue the xset command with the appropriate flag. See the
The xsetroot command has a -def flag that
enables you to return the display to its default settings. See the
One of the features of the xrdb utility is that it uses a
C preprocessor when it loads the resource definition file. This feature allows
you to have #include and #ifdef statements and some
other programming constructs in your resource definition files. In addition,
you can define and undefine symbols by using the -D or -U flags.
The following example shows how you might include an #ifdef
directive in your resource definition file that defines the colors to use
for DECterm windows on color workstation monitors and the black and white
values to use with noncolor monitors:
You can use the xrdb -query command to see the current
settings for your system. If you want to change some of these resources,
you can create a resource definition file and use the xrdb -merge
filename command to add or replace existing definitions with your changes.
With the -merge flag, xrdb replaces resource
definitions for resources that are already defined for your system with those
in the file you specify. If you have included resource definitions in that
file for previously undefined resources, those new definitions are added.
All other existing definitions remain the same.
There is also an xrdb -load filename command that
you can use to erase all previous resource definitions and only use those
in the file you specify. By default, xrdb behaves in this manner.
Most of the time, you will probably want to use the xrdb -merge
filename command because you will not want to lose the default settings
for your environment.
For more information on the xrdb utility, see the X Window System User's Guide and the
The utility has three basic mapping functions:
You can issue xmodmap commands during your work session or
include them in an X session script. You can also create xmodmap
definition files for the utility to read at startup time or when you invoke
the utility during your work session.
The xmodmap command has the following syntax:
xmodmap [flags] [filename]
When you use the xmodmap command with no flags, it displays
the current modifier key map, the keys that can be used to modify other keys.
While this information can be helpful in some instances, most of the time
you do not want to change these key mappings. The following example shows
the xmodmap display:
The items in the left column are the logical key names for the modifier
keys. The items to the right are the keysym specifiers with the
hardware hexadecimal keycode in parentheses. For example, the logical key
name shift has two keys on the keyboard that perform the shift
function. Their keysyms are Shift_R and Shift_L. The hardware hexadecimal keycodes for these keys are Oxab
and Oxae respectively.
Using the xmodmap -pke command, you can see the decimal
keycodes and the keysym name or names that have been assigned to
each keycode. Note that keycode numbers vary depending on the keyboard model
that you have connected to your workstation.
When there are two names, the second one indicates which key function
is processed when the shift modifier key is pressed in combination
with that physical key. The following example shows a portion of the output:
You use keycodes and keysyms in the xmodmap -e command to modify the action that takes place when a particular keyboard
key is pressed. For example, you can change the Select key on Digital LK201/401
keyboards to perform the Delete function:
You can have your own personal keymapping file by creating a file with xmodmap definitions, such as the following:
To have the file processed whenever you log in, include an xmodmap command in your X session script. For example, if you named your key
definition file .Xmodmap and located it in your home directory,
you could include the following line in your X session script:
For more details about the xmodmap utility, see the X Window System User's Guide and the
You can use a session script to invoke certain applications when you
log in and place various windows on your display in specific positions. You
can set the window manager in your session script as well as specify colors,
fonts, and window features. The file can also contain xmodmap
definitions or call an xmodmap definition file.
You can use a script to define certain environment variables before
the session manager starts. For example, the following script defines the PRINTER environment variable, sets the default path, and invokes dxsession as the session manager.
The next example invokes the
xconsole program and starts an xterm window as background processes.
It then starts the twm window manager in the foreground. The twm window manager becomes the session's controlling process; that is,
the session will last as long as the twm process is running. When twm exits, the .xsession script completes and the user's
X session is over. If the last command line in the script had ended with an
ampersand (&), the .xsession script would immediately complete
and exit, the X session would be over, and xdm would cause the
display to reset to the login box.
With the xconsole program running, messages that are usually
sent to /dev/console appear in the xconsole window on
the display. The xclock command places a clock client window on
the display. The xterm -geometry -ls command starts
an xterm window at the screen location specified with the -geometry flag and starts the login shell in that window.
You can include a wide variety of customizations in an X session script
as shown in the following example. The comments within the example explain
the code.
dxterm -bg "pale green" -fg "sandy brown" &
Starts a DECterm window with a pale green background. The text and
graphics appear in sandy brown.
xterm -iconic -name Letters &
Creates an xterm window, but places it immediately in the
icon state. The name of the icon is Letters.
dxcalc -geometry +0-0 &
Invokes the DECwindows Calculator application and places the window
in the lower left corner of the screen.
3.3 Using Resource Definitions
Resources are defined in several places in the X Window System
environment. There are resource definition files such as local and groupwide Xdefaults
files
that contain resource definitions for your X workstation environment. Then
there are resource definitions in window applications based on the X Toolkit
(including DECwindows and OSF/Motif Toolkit applications) that determine the
various visible aspects of the application.
3.3.1 Resource Definition Structure
The syntax for resource definitions is as follows:
accessx*background: lightblue
accessx.mousekeys.statusbox: darkblue
editres(1X) reference page for
details.
3.3.2 Resource Definition Files
A resource definition file consists of lists of resource definitions
and comments. Comments are prefixed by an exclamation point (!). You can
use the exclamation point to disable a definition that you do not want to
use, but want to retain in the file.
3.4 Using Client Utilities for Customization
The preceding section
referred to some utilities that are useful in creating and processing resource
definitions. The next sections describe each of the following client utilities
that you can use to customize resources:
3.4.1 The editres Utility
The editres
utility is a dynamic
resource editor for use with X Toolkit applications. Motif applications are
also X Toolkit applications and also work with editres. The utility
allows users and application programmers to view the full widget hierarchy
of any X Toolkit client that understands the editres protocol.
You can use editres to apply resource definitions to an application
and see the results immediately. Users can save these definitions by having editres append the definitions to an existing X resource definitions
file such as .Xdefaults.
3.4.2 The xset Utility
The xset
utility is described
in the reference page as the "user preference utility for X".
You can use this utility to set various user preference options for your
workstation's display. These options include the following:
xset(1X)
reference page for the description of each flag.
3.4.3 The xsetroot Utility
You can use the xsetroot
utility to customize
the attributes of the display background on your workstation. These attributes
include the color and shape that the pointer cursor has, except in client
windows where those settings have been defined by the client applications,
and the pattern and colors of the display background; that is, the root window.
You can use xsetroot to do such things as create plaid display
backgrounds or change the shape of the pointer cursor to look like a hand
or some other object.xsetroot(1X)
reference page for more details about the utility.
3.4.4 The xrdb Utility
The xrdb
utility manages the
X server resource database. This utility gets and sets the contents of the
RESOURCE_MANAGER
property for the display
window for screen 0 on your workstation, or the SCREEN_RESOURCES
property for the display
window of any or all screens. This utility is generally invoked from users'
X session scripts. Resource definitions are loaded directly into the X server.
#ifdef COLOR
DXterm*background: lightblue
DXterm*foreground: darkblue
#else
DXterm*background: gray
DXterm*foreground: black
#endif
xrdb(1X) reference page.
3.4.5 The xmodmap Utility
You can use the xmodmap
utility to modify
the mappings for keyboard keys as well as mouse buttons.
xmodmap -e "Control_R = Shift_R"
xmodmap -e "keycode 243 = slash exclam"
xmodmap -e "pointer = 3 2 1"
xmodmap: up to 2 keys per modifier, (keycodes in parentheses)
shift Shift_R (0xab), Shift_L (0xae)
lock BadKey (0xb0)
control BadKey (0xaf)
mod1 Multi_key (0xad), Multi_key (0xb1)
mod2 Alt_L (0xac), Alt_R (0xb2)
mod3
mod4
mod5
keycode 242 = semicolon colon
keycode 243 = slash question
keycode 244 =
keycode 245 = equal plus
keycode 246 = bracketright braceright
stdin
keycode 247 = backslash bar
keycode 248 =
keycode 249 = minus underscore
keycode 250 = bracketleft braceleft
keycode 251 = apostrophe quotedbl
xmodmap -e "keysym Select = Delete"
! Make the comma shift be < and the period shift be >.
keysym comma = comma less
keysym period = period greater
! Replace the Help key with the escape function.
keysym 124 = escape
xmodmap $HOME/.Xmodmap
xmodmap(1X) reference
page.
3.4.6 Utilities Using the X Keyboard Extensions
Several applications that make use of XKB features are also new with Digital UNIX
Version 4.0. These applications include the following:
3.5 Using an X Session Script
Once you have decided on how you
want to customize the X Window System on your workstation, an effective way
to preserve that environment is to use an X session script. Note that X session
scripts also work with CDE's dtlogin manager.
#!/bin/csh
setenv $PRINTER ln08r
set path=($HOME/bin /bin /usr/bin /usr/bin/mh /usr/bin/X11 \
/usr/local /usr/local/bin)
exec dxsession
#!/bin/sh
xconsole -geometry 480x130-0-0 -daemon -notify -verbose
-fn fixed -exitOnFail
xclock &
xterm -geometry 80x24+10+10 -ls &
exec twm
Example 3-1: Session Script
#!/bin/csh
#
# Define environment variables, paths, and so on. Keeping these
# definitions in a separate file is useful. That way, .login
# and/or .cshrc can reference the same set of definitions.
#
source ~/.environ.csh
#
# Create a pipe for dxconsole to read from, so it can display the
# output of other commands.
#
setenv XSESSION_PIPE .xsession_pipe.$DISPLAY
if ! { test -p .xsession_pipe.$DISPLAY } then
/usr/sbin/mknod $XSESSION_PIPE p
endif
#
# Use xrdb to load the resources in the .Xresources file into the
# X server's resource database.
#
if ( -f .Xresources ) then
xrdb -load -retain .Xresources
endif
#
# Determine whether the display is the local graphics display,
# that is, :0 or local:0 .
#
if ( "`echo $DISPLAY | cut -d':' -f1`" == || \
"`echo $DISPLAY | cut -d':' -f1`" == "local" ) then
#
# These applications are run only if the display is local.
#
dxconsole < $XSESSION_PIPE &
#
# Figure out how many screens the display has.
#
set SCREENS=`xdpyinfo | grep "number of screens" \
| cut -f 4- -d " "`
#
# The xset b flag sets the bell volume, pitch, and duration.
# The xset c flag controls the key click.
# The xset m flag controls the mouse acceleration and
# threshold.
# The xset s flag sets the screen save parameters.
#
xset b 18 400 100 c 22 m 7 5 s 600 600 >& $XSESSION_PIPE
#
# For each screen, set the background color and the colors
# and shape of the cursor. This example uses custom colors
# defined in an Xcms data file as well as customized bitmaps
# (created # with /usr/bin/X11/bitmap) to define the shape
# of the cursor.
#
set SCREEN=0
while ( $SCREEN < $SCREENS )
xsetroot -solid DarkBlueBackground -fg red -bg yellow \
-cursor cursor.bmp cursor_mask.bmp -display $DISPLAY.1 \
>& $XSESSION_PIPE
@ SCREEN=($SCREEN + 1)
end
# Set the SCREEN variable to the screen number of the highest
# numbered screen.
#
@ SCREEN=($SCREENS - 1)
#
# The xbiff command displays a small mailbox image that lets
# you know when you have mail. This example uses the 'letters'
# bitmap from /usr/include/X11/bitmaps as well as custom
# bitmaps for the full and empty bitmaps and shape masks.
#
xbiff -shape -update 120 -geometry 60x60-0+0 \
-display $DISPLAY.0 -bg black -fg white \
-bd '#191919195c5c' -xrm "XBiff*fullPixmap: letters" \
-xrm "XBiff*emptyPixmap: $HOME/bitmaps/one.xbm" \
-xrm "XBiff*fullPixmapMask: $HOME/bitmaps/lettersmask.xbm" \
-xrm "XBiff*emptyPixmapMask: $HOME/bitmaps/one.xbm" \
>& $XSESSION_PIPE &
# start oclock on screen 0
oclock >& $XSESSION_PIPE &
#
# Start dxcalendar, xload, and dxmail on the highest numbered
# screen.
#
dxcalendar -display $DISPLAY.$SCREEN >& $XSESSION_PIPE &
xload -geometry +0-0 \
-display $DISPLAY.$SCREEN >& $XSESSION_PIPE &
dxmail -display $DISPLAY.$SCREEN >& $XSESSION_PIPE &
#
# Use xmodmap to reorder the mouse buttons and remap the Shift
# Lock key on the LK401 or LK201 keyboard to be Escape.
#
xmodmap -e 'pointer = 2 3 1' >& $XSESSION_PIPE
xmodmap -e "clear lock" >& $XSESSION_PIPE
xmodmap -e "keycode 176 = Escape" >& $XSESSION_PIPE
#
# Start the Motif Window Manager as the controlling process.
# When mwm exits, the X session will be over.
# Using the shell's built-in exec command saves the cost of
# creating another process.
#
exec mwm -multiscreen >& $XSESSION_PIPE
#
# End of Session
#
else
#
# These applications are run only if the display is not local,
# that is, the session is run on a remote X Terminal.
#
# Invoking dxconsole is useful for displaying the stdout of
# the commands that run, even though as a remote display,
# the display console output will not actually be displayed.
#
dxconsole < $XSESSION_PIPE &
xset b 18 400 100 c 22 m 7 5 s 600 600 >& $XSESSION_PIPE
xsetroot -solid DarkBlueBackground -fg red -bg yellow \
-cursor cursor.bmp cursor_mask.bmp >& $XSESSION_PIPE
oclock&
#
# If the X Terminal is running its own local window manager,
# mwm is likely to exit immediately, so it is not used as the
# controlling process.
#
mwm >& $XSESSION_PIPE &
#
# Instead, xterm is used as the controlling process. When
# xterm exits, the X session will be over.
#
exec xterm
#
# End of Session
#
endif