SUMMARY: C shell environment variables (again).

From: Peter Watkins (peter@jrc.nl)
Date: Fri Dec 16 1994 - 15:39:59 CST


----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 17

OK, I give up! I have received so many requests for the
X FAQ that I will post it to sun-managers to save me replying
individually to all and sundry.

Dr Peter Watkins.
.___________________________________________________________________________.
| Joint Research Centre, | |
| Commission of the European Communities, | Tel: (+31)-2246-5120 |
| P.O. Box 2, | Fax: (+31)-2246-1449 |
| 1755 ZG Petten, | Email: peter@jrc.nl |
| The Netherlands. | |
|_________________________________________________|_________________________|

----------
X-Sun-Data-Type: default
X-Sun-Data-Name: x.faq
X-Sun-Content-Lines: 104

You can use several environment variables to control how resources are
loaded for your Xt-based programs -- XFILESEARCHPATH,
XUSERFILESEARCHPATH, and XAPPLRESDIR. These environment variables
control where Xt looks for application-defaults files as an
application is initializing. Xt loads at most one app-defaults file
from the path defined in XFILESEARCHPATH and another from the path
defined in XUSERFILESEARCHPATH.

Set XFILESEARCHPATH if software is installed on your system in such a
way that app-defaults files appear in several different directory
hierarchies. Suppose, for example, that you are running Sun's Open
Windows, and you also have some R4 X applications installed in
/usr/lib/X11/app-defaults. You could set a value like this for
XFILESEARCHPATH, and it would cause Xt to look up app-defaults files
in both /usr/lib/X11 and /usr/openwin/lib (or wherever your
OPENWINHOME is located):

        setenv XFILESEARCHPATH /usr/lib/X11/%T/%N:$OPENWINHOME/lib/%T/%N

The value of this environment variable is a colon-separated list of
pathnames. The pathnames contain replacement characters as follows
(see XtResolvePathname()):

        %N The value of the filename parameter, or the
                application's class name.
        %T The value of the file "type". In this case, the
                literal string "app-defaults"
        %C customization resource (R5 only)
        %S Suffix. None for app-defaults.
        %L Language, locale, and codeset (e.g. "ja_JP.EUC")
        %l Language part of %L (e.g. "ja")
        %t The territory part of the display's language string
        %c The codeset part of the display's language string

Let's take apart the example. Suppose the application's class name is
"Myterm". Also, suppose Open Windows is installed in /usr/openwin.
(Notice the example omits locale-specific lookup.)

        /usr/lib/X11/%T/%N means /usr/lib/X11/app-defaults/Myterm
        $OPENWINHOME/lib/%T/%N means /usr/openwin/lib/app-defaults/Myterm

As the application initializes, Xt tries to open both of the above
app-defaults files, in the order shown. As soon as it finds one, it
reads it and uses it, and stops looking for others. The effect of
this path is to search first in /usr/lib/X11, then in /usr/openwin.

Let's consider another example. This time, let's set
XUSERFILESEARCHPATH so it looks for the file Myterm.ad in the current
working directory, then for Myterm in the directory ~/app-defaults.

        setenv XUSERFILESEARCHPATH ./%N.ad:$HOME/app-defaults/%N

The first path in the list expands to ./Myterm.ad. The second expands
to $HOME/app-defaults/Myterm. This is a convenient setting for
debugging because it follows the Imake convention of naming the
app-defaults file Myterm.ad in the application's source directory, so
you can run the application from the directory in which you are
working and still have the resources loaded properly.

NOTE: when looking for app-default files with XUSERFILESEARCHPATH,
      for some bizarre reason, neither the type nor file suffix is
      defined so %T and %S are useless.

With R5, there's another twist. You may specify a customization
resource value. For example, you might run the "myterm" application
like this:

        myterm -xrm "*customization: -color"

If one of your pathname specifications had the value
"/usr/lib/X11/app-defaults/%N%C" then the expanded pathname would be
"/usr/lib/X11/app-defaults/Myterm-color" because the %C substitution
character takes on the value of the customization resource.

The default XFILESEARCHPATH, compiled into Xt, is:

                /usr/lib/X11/%L/%T/%N%C:\ (R5)
                /usr/lib/X11/%l/%T/%N%C:\ (R5)
                /usr/lib/X11/%T/%N%C:\ (R5)
                /usr/lib/X11/%L/%T/%N:\
                /usr/lib/X11/%l/%T/%N:\
                /usr/lib/X11/%T/%N

(Note: some sites replace /usr/lib/X11 with a ProjectRoot in this
batch of default settings.)

The default XUSERFILESEARCHPATH, also compiled into Xt, is

                <root>/%L/%N%C:\ (R5)
                <root>/%l/%N%C:\ (R5)
                <root>/%N%C:\ (R5)
                <root>/%L/%N:\
                <root>/%l/%N:\
                <root>/%N:

<root> is either the value of XAPPLRESDIR or the user's home directory
if XAPPLRESDIR is not set. If you set XUSERFILESEARCHPATH to some
value other than the default, Xt ignores XAPPLRESDIR altogether.

Notice that the quick and dirty way of making your application find
your app-defaults file in your current working directory is to set
XAPPLRESDIR to ".", a single dot. In R3, all this machinery worked
differently; for R3 compatibilty, many people set their XAPPLRESDIR
value to "./", a dot followed by a slash.



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:09:17 CDT