This section covers:
Setting environment variables
Setting resources
Using display-dependent sessions
Running scripts at login
Recovering a back-up session
To set system-wide environment variables, create a file in the /etc/dt/config/Xsession.d directory that sets and exports the variable.
For example, if you create an executable ksh script, /etc/dt/config/Xsession.d/myvars, containing:
export MYVARIABLE="value"
then the variable MYVARIABLE
will be set in each user's environment at the next login.
For example:
export MYVARIABLE="value"
sets the variable MYVARIABLE
in each user's environment at the next login.
Session Manager does not automatically read the .profile or .login file. However, it can be configured to use these files; see "Optionally Sourcing the .profile or .login Script".
To set system-wide resources, add the resources to the file /etc/dt/config/language/sys.resources. (You may have to create the file.)
.dtprofile only supports /bin/sh or /bin/ksh syntax.
For example, if in /etc/dt/config/C/sys.resources you specify:
AnApplication*resource: value
then the resource AnApplication*resource will be set in each user's RESOURCE_MANAGER
property at the next login.
To set personal resources, add the resources to the file HomeDirectory/.Xdefaults.
You can set display-specific resources for all desktop users on the system. Also, users can set display-specific resources limited to their own session. This enables you to specify resources depending upon which display the user uses to log in to the desktop.
To set display-specific resources for all desktop users on the system, create the file /etc/dt/config/language/sys.resources that specifies the display-specific resources.
To set personal display-specific resources, specify the resource in HomeDirectory/.Xdefaults.
You delimit these resources by enclosing them in cpp conditional statements. A DISPLAY_
displayname macro is defined depending upon the value of the $DISPLAY
variable. This is done by converting all . (period) and : (colon) characters to _ (underscores), stripping off any screen specification, and finally prefixing DISPLAY_
to the result.
For example, a $DISPLAY
of :0 would be DISPLAY_0
, and a $DISPLAY
of blanco.gato.com:0.0 would be DISPLAY_blanco_gato_com_0. The resulting value can be used as part of a cpp test in a session resource file. For example, if in /etc/dt/config/C/sys.resources you specify:
Myapp*resource: value
#ifdef DISPLAY_blanco_gato_com_0 Myapp*resource: specialvalue1 #endif
#ifdef DISPLAY_pablo_gato_com_0 Myapp*resource: specialvalue2 #endif
the resource MyApp*resource will be set in RESOURCE_MANAGER
to specialvalue1 when the user logs in on display blanco.gato.com:0; specialvalue2 when the user logs in on pablo.gato.com:0; and value when the user logs in on another display.
You can specify alternate applications to start as part of a user's initial session.
Copy /usr/dt/config/language/sys.session to /etc/dt/config/language/sys.session.
Modify the new sys.session file.
Each entry in sys.session appears as:
dtsmcmd -cmd command_and_options
To start an additional application as part of a user's initial session, specify a new sys.session entry with a full path name. For example, to start /usr/bin/X11/xclock as part of a user's initial session, add an xclock entry to /etc/dt/config/C/sys.session:
# # Start up xclock... # dtsmcmd -cmd "/usr/bin/X11/xclock -digital"
A user can set up a display-specific session to tune a session to a particular display.
Copy the HomeDirectory/.dt/sessions directory to HomeDirectory/.dt/display where display is the real, unqualified host name (pablo:0 is valid, pablo.gato.com:0 or unix:0 is not).
For example, to create a display-specific session for display pablo.gato.com:0:
cp -r HomeDirectory/.dt/sessions HomeDirectory/.dt/pablo:0
When the user next logs in on display pablo.gato.com:0, the Session Manager will start that display-specific session.
Users can specify that additional commands be started when they log in to their desktop sessions. This is useful for setting up X settings that are not saved by Session Manager. For example, the user can use xsetroot to customize the root (workspace) pointer. Another use would be to start applications that are unable to be saved and restored by Session Manager. If an application will not restart when the session is restored, the user can start the client using this method.
Generally this file is a script and must have execute permission. Processes started in sessionetc should be run in the background.
Do not use sessionetc to start clients that are automatically restored by Session Manager. Doing so can cause multiple copies of the application to be started. You may not be able to see the copies immediately because the windows may be stacked on top of one another.
A companion file to sessionetc is sessionexit. Use sessionexit to perform some operation at session exit that is not handled by Session Manager.
Create the file HomeDirectory/.dt/sessions/sessionexit containing the commands.
Like sessionetc, this file is usually a script with execute permission.
When Session Manager saves a session, the session information is stored in the HomeDirectory/.dt/sessions directory or in the HomeDirectory/.dt/display directory if using a display-specific session. In these directories, Session Manager creates a subdirectory named current or home to store information for the respective current or home session. Before the session information is stored, Session Manager makes a backup of the prior session with that name and stores it in current.old or home.old.
Log in using the Failsafe Session or Command Line Login from the login screen.
Copy the backup session directory to the active name. For example, to recover the backup home session:
cp -r HomeDirectory/.dt/sessions/home.old \ HomeDirectory/.dt/sessions/home
Display-specific sessions can be recovered in the same manner.
Session Manager logs each user's session startup progress in this file.