2 Customizing the X Environment

With the Tru64 UNIX operating software, you can use resource definitions to customize and manage your workstation environment and certain elements of X Window System, OSF/Motif, and DECwindows applications that you are running. This chapter contains information about how to specify and modify these resource definitions. The following documentation contains more details:

The appendix on resources and keysym mappings in X Window System Administrator's Guide (O'Reilly & Associates, Inc.)

Part II of the X Window System User's Guide OSF/Motif 1.2 Edition, (O'Reilly & Associates, Inc.)

2.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.

X resources are defined for display aspects of the Tru64 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, xclock, and even the X Display Manager xdm. The Tru64 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.

2.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.

There are three ways to set resources:

Using command-line flags when invoking a particular client such as dxterm, xterm, or xclock
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 2.2 discusses this method.

Defining resources in files that are processed whenever an X client application starts
These files include $HOME/.Xdefaults-hostname and files to which the XENVIRONMENT variable points. Resource definition files can be located in the user's home directory and in the /usr/lib/X11/app-defaults directory, which is part of the operating software.
The system administrator can use systemwide files to establish uniform settings for small or large groups of users; or special individual settings. Section 2.3 discusses this method.

Defining resources in client applications
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 2.4 describes some utilities that help users and programmers specify resource definitions.

2.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:

Systemwide application default resource definitions
Resource definitions for the Tru64 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.

User-specific default resource definitions
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 default resource definitions
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.

Resource database resource definitions
Some users use a resource database loaded by the X Server Resource Database utility (xrdb) to specify display-specific default resource settings.

.Xdefaults file resource definitions
If no resource database exists for the user, the X server applies the resource definitions in the $HOME/.Xdefaults file.

Command-line flags
Users can change some resource definitions by specifying the new resource settings on the command line when they invoke the client application. Section 2.2 and the 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.

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:

XFILESEARCHPATH
This environment variable is used to set the path for systemwide application-specific resource definition files.

XUSERFILESEARCHPATH
This environment variable is used in place of $HOME for application-specific user resource definition files.

XAPPLRESDIR
If this environment variable is defined and XUSERFILESEARCHPATH is not, the search path becomes:
```
$XAPPLRESDIR/%L/%N:$XAPPLRESDIR/%l/%N:$XAPPLRESDIR/%N:$HOME/%N
 
```
$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:
```
$HOME/%L/%N:HOME/%l/%N:$HOME/%N
 
```
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.

2.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 2.4.4 for more information.)

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.

2.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.

Table 2-1 lists the standard command-line flags and the resources they modify.

Table 2-1: Standard Command-line Flags

Flag	Resource	Description
`-bg -background`	`background`	Sets the background color of the window.
`-bd -bordercolor`	`borderColor`	Sets the color of the window border.
`-bw -borderwidth`	`borderWidth`	Sets the width of the window border in pixels.
`-display`	`display`	Specifies the display on which the client runs.
`-fn` `-font`	`font`	Sets the font used for text display.
`-fg -foreground`	`foreground`	Sets the window's foreground color that is used for the text or graphics.
`-geometry`	`geometry`	Specifies a geometry string that sets the startup size and placement of the window.
`-iconic`	`iconic`	Invokes the application in the iconic state.
`-name`	`name`	Specifies the name of the application. This name is used for the window icon.
`-rv -reverse`	`reverseVideo`	Reverses the foreground and background colors.
`+rv`	`reverseVideo`	Restores the foreground and background colors to their current specifications.
`-selectionTimeout`	`selectionTimeout`	Specifies the timeout period in milliseconds. This value determines the timeout period within which two communicating applications must respond to one another after a selection request.
`-synchronous`	`synchronous`	Enables synchronous debugging mode.
`+synchronous`	`synchronous`	Disables synchronous debugging mode.
`-title`	`title`	Specifies the application title that is used in the window's title bar.
`-xnllanguage`	`xnlLanguage`	Sets the language, territory, and National Language Support codeset.
`-xrm`		Allows you to specify a resource name and value to override any defaults.

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:

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.

2.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.

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.

2.3.1 Resource Definition Structure

The syntax for resource definitions is as follows:

object.subobject[.subobject]....attribute: value

The parameters have the following definitions:

object: The client program or a specific instance of the client program. This parameter can specify any client, such as a DECterm window or the clock application.
subobject: A subobject is an element of the object client program. A subobject corresponds to the widgets that make up the client program. The number of subobjects you need to include to reach the particular resource you want to specify is determined by the widget hierarchy of the client program.
attribute: This parameter specifies the characteristic that you want to define. The attribute must be a feature of the last subobject you listed. The attribute refers to such things as font, color, or location of the subobject.
value: This parameter specifies the definition for the attribute. Definitions can include color names, pixel coordinates, and Boolean values such as True or False.

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 2-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:

accessx*background:   lightblue

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:

accessx.mousekeys.statusbox:   darkblue

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 2.4.1 and the editres(1X) reference page for details.

2.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.

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 Tru64 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 2.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.

2.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:

editres

xset

xsetroot

xrdb

xmodmap

2.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.

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.

2.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:

Volume, pitch, and duration of the computer's beep sound

Whether the keyclick sound is enabled or disabled and what volume it has

Font path that specifies which fonts the X server can use

Control of the use of LED lights for such things as Shift/Caps Lock

Control of the mouse for such things as pointer acceleration and the length of the delay time until the maximum acceleration speed is reached

Pixel color values

Whether the autorepeat feature for keys is enabled or disabled

Screen save parameter settings

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 xset(1X) reference page for the description of each flag.

2.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.

The xsetroot command has a -def flag that enables you to return the display to its default settings. See the xsetroot(1X) reference page for more details about the utility.

2.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.

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:

#ifdef COLOR
DXterm*background:      lightblue
DXterm*foreground:      darkblue
#else
DXterm*background:      gray
DXterm*foreground:      black
#endif

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 xrdb(1X) reference page.

2.4.5 The xmodmap Utility

You can use the xmodmap utility to modify the mappings for keyboard keys as well as mouse buttons.

The utility has three basic mapping functions:

It reassigns a modifier function to a different key on the keyboard. For example, to have the Right Shift key perform the Control modifier function, use the following command:
```
xmodmap -e "Control_R = Shift_R"
 
```

It reassigns a keyboard function to a different key on the keyboard. For example, to have the exclamation point (!) be sent to the computer when you press the vertical bar key, use the following command:
```
xmodmap -e "keycode 243 = slash exclam"
```

It reassigns pointer functions to different mouse buttons. For example, if you are left handed, you could use the following command to change the order of the buttons on the mouse from 1 2 3 to 3 2 1:
```
xmodmap -e "pointer = 3 2 1"
 
```

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:

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

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:

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

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:

xmodmap -e "keysym Select = Delete"

You can have your own personal keymapping file by creating a file with xmodmap definitions, such as the following:

! 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

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:

xmodmap $HOME/.Xmodmap

For more details about the xmodmap utility, see the X Window System User's Guide and the xmodmap(1X) reference page.

2.4.6 Utilities Using the X Keyboard Extensions

Several applications that make use of XKB features are also new with Tru64 UNIX Version 4.0. These applications include the following:

xkbcomp
The xkbcomp utility is the XKB keymap compiler and converts XKB keymap source files into one of several output formats. It will also optionally load a keymap directly into the server if you specify the display as the output file. Each of the xmodmap keymaps located in /usr/lib/X11/keymaps for X11 R5 has been converted to XKB format for X11 R6. These new keymaps are located in/usr/lib/X11/xkb. Refer to the xkbcomp(1X) reference page for or run xkbcomp with the -? switch for more information.

xkbprint
The xkbprint utility creates a PostScript representation of an XKB keymap. If you specify the display as the input file, it will read the XKB geometry from the server. Refer to the xkbprint reference page or run xkbprint with the -? switch for more information.

xkbdfltmap
The xkbdfltmap utility queries the kernel for the language and keyboard on the console. Given this information, Xdec will examine the/usr/lib/X11/xkb/keymaps.dir file to determine the default keymap to use. The xkbdfltmap utility will then display the appropriate xkbcomp command to run to download the default XKB map to the server. If xkbdfltmap is run with the -exec switch, it will automatically execute the xkbcomp command for you. Refer to the xkbdfltmap reference page or run xkbdfltmap with the -? switch for more information.

dxkbledpanel
The dxkbledpanel utility displays the state of the keyboard indicators. This is useful for monitoring and changing the state of indicators that may not have keyboard LEDs. For example, the group indicator does not always have an LED on every keyboard. Refer to the dxkbledpanel reference page or run dxkbledpanel with the -? switch for more information.

dxkeyboard
The dxkeyboard utility allows you to select a localized keymap based upon your selection of language and keyboard type. The dxkeyboard utility optionally saves your selections and will load them if it is run with the -load switch. The dxkeyboard utility is available as the Keyboard Options object under CDE's Application Manager in the Desktop_Apps folder. Refer to the dxkeyboard reference page or run dxkeyboard with the -? switch for more information.

accessx
The accessx application for X11 R5 has been ported to use the XKB protocol for X11 R6. Refer to the accessx(1X) reference page for further information.

2.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.

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.

#!/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

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.

#!/bin/sh
xconsole -geometry 480x130-0-0 -daemon -notify -verbose
     -fn fixed -exitOnFail
xclock &
xterm -geometry 80x24+10+10 -ls &
exec twm

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.

Example 2-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 xcalendar, xload, and dxmail on the highest numbered
    # screen.
    #
    xcalendar -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

2.6 Bypassing the Login Manager

Although Digital does not recommend bypassing the xdm or dtlogin login manager, there are several ways you could accomplish this. The following steps describe one method that can be used to disable the xdm or dtlogin login manager:

Disable automatic startup of xdm.

# mv /sbin/rc3.d/S95xlogin /sbin/rc3.d/xS95xlogin

Write a script that will start the X server and then start your application. For example:

    #!/bin/csh
    #
    # Start the X server.
    # Using the -ac option disables authentication checking.
    #
    /usr/bin/X11/X -ac &
    #
    # define anything you might need in your environment
    #
    setenv DISPLAY :0
    #
    # You may also configure the X server's font path, keyboard, etc.
    # by calling Xsetup_0.  This will also start dxconsole, but if
    # you don't want that make your own customized version of
    # Xsetup_0 and use that.  But bear in mind that the X server
    # will reset when its last connection is closed, so you may need
    # to hold open a connection, something like this:
    #
    /usr/bin/X11/xlogo&
    /var/X11/xdm/Xsetup_0
    #
    # Now start your application
    #
    /path-to-wherever/your-application &

Create a link to your script in rc3.d named S95*:

# ln -s /path-to-wherever/my-startup-script /sbin/rc3.d/S95whatever

For a clean shutdown, disable stopping of xdm or dtlogin:
```
# mv /sbin/rc0.d/K19xlogin /sbin/rc0.d/xK19xlogin
```

Write a shutdown script for your application and create a symbolic link to it in /sbin/rc0.d/K19whatever. This step is optional and only required if there is some clean up you need to do in case the system is shut down.