--- Begin Message ---
- To: Debian Bug Tracking System <submit@bugs.debian.org>
- Subject: tetex-bin: xdvi wrapper should set XUSERFILESEARCHPATH not XFILESEARCHPATH
- From: Matt Swift <swift@alum.mit.edu>
- Date: Thu, 06 May 2004 01:50:10 -0400
- Message-id: <87llk6gl4d.fsf@beth.swift.xxx>
Package: tetex-bin
Version: 2.0.2-10
Severity: normal
The xdvi wrapper has the reasonable goal (stated in the comments) of
allowing users to put an XDvi application-specific X resource file in
the texmf tree(s). The way the wrapper does this can be improved in
several ways, noted below with the word IMPROVEMENT in capitals.
Some background is necessary before discussion:
ASXRF: Application-Specific X Resource File (e.g.,
/etc/X11/app-defaults/XDvi).
system path: One of two paths that libXt always searches for ASXRFs.
It comprises the elements listed in envariable
$XFILESEARCHPATH, if that is set, OR ELSE a compiled-in
libXt default.
system-ASXRF: The first ASXRF in the system path, if any. This ASXRF
will be loaded; any ASXRFs occurring later in the
system path will not be loaded.
user path: The other of two paths that libXt always searches for
ASXRFs. It comprises the contents of envariable
$XUSERFILESEARCHPATH, if it is set, OR ELSE a
compiled-in libXt default. The default value refers to
envariable $APPLRESDIR, whose value if not set is
defaulted to the value of $HOME.
user-ASXRF: The first ASXRF in the user path, if any. This ASXRF
will be loaded; any ASXRFs occurring later in the user
path will not be loaded. In the case there is both a
system-ASXRF and a user-ASXRF, BOTH will be loaded; and
in the case a resource is assigned a value in both
files, the value in the user-ASXRF will prevail.
NOTE the information in the last sentence does not
appear in the manual page for X(1) or anywhere else
that I can find. Assuming others can verify this, it
would be an IMPROVEMENT to include this information in
the xdvi manual page and in the xdvi wrapper script
comments and submit an X bug report.
texmf-ASXRF: The first ASXRF in the texmf tree, as searched by the
kpathsea library (configured by texmf.cnf). Need not
exist (but usually will in a Debian system). Note
Kpathsea knows only about the first qualifying file it
looks for. Will not be loaded by libXt unless it
is the system- or user-ASXRF.
texmf-ASXRFD: The directory containing the texmf-ASXRF.
See the X(1) manual page for most of the information above, which is
confirmed in experiment.
Note that within a typical X session, there is a hierarchical cascade
of values for resources: values specified on the command-line override
values in the resource database (i.e., xrdb) which is initialized from
a user resource file (e.g., ~/.Xresources) which overrides machine
default resource files. None of these needs to exist or assign values
to any resources. Then comes the user-ASXRF and the system-ASXRF, if
they exist. Then comes compiled-in application defaults, which always
exist. Note that the selection of the user- and system-ASXRF files is
not the result of a cascade of defaults, but the result of the
particular scheme described above.
I am concerned here only with the process of choosing the two ASXRF
files and how it is manipulated by the xdvi wrapper script.
In the case there is a texmf-ASXRF, the current xdvi wrapper script
does the following:
(1) sets $APPLRESDIR to texmf-ASXRFD
(2) prepends texmf-ASXRFD to $XFILESEARCHPATH
The consequences are:
(1) The user's prior value of $APPLRESDIR is ignored.
(2) If a texmf-ASXRF exists, it will be loaded as the
system-ASXRF.
It is an easy IMPROVEMENT to make the xdvi wrapper heed a prior value
of $APPLRESDIR, without breaking compatibility with X11R3 (if that
even remains an important goal). There's not much to be gained by
doing so, but why not if we can.
It would be an IMPROVEMENT to ensure that values assigned to
$APPLRESDIR end with a terminal /, which is required by POSIX (search
for POSIX in the the X(1) manual page; this information does not
appear in the detailed discussion of the variable -- another
documentation bug that ought to be submitted if others agree and can
verify it really is a POSIX requirement).
Note that in the situation that there exists both a user-ASXRF and a
system-ASXRF for xdvi before the xdvi wrapper is run, then in order to
load a texmf-ASXRF, the xdvi wrapper must sacrifice loading either the
user- or the system-ASXRF.
Ideally, I think one should be able to arrange for as many ASXRFs as
we wanted to be loaded, with defaults cascading. It appears to me,
however, that the much more flexible resource database (managed by
xrdb) is expected to supersede entirely the use of environment
variables and ASXRFs. If true, then we are concerned mainly with
legacy use of ASXRFs.
In a vanilla Debian system, there is a texmf-ASXRF
(/usr/share/texmf/xdvi/XDvi) which is a symlink to
/etc/X11/app-defaults/XDvi, which is ALSO the vanilla system-ASXRF
(because of the symlink /usr/X11R6/lib/X11/app-defaults ->
/etc/X11/app-defaults).
With vanilla Debian TeX and X installations, the /usr/share/texmf/xdvi
symlink is redundant: it may as well not be there. (And the fact that
it is there helps to obscure the problems with non-vanilla
configurations.) So we ask, what modifications to the vanilla setups
are users most likely to make; and which ones should they be
encouraged to make.
Administrators or users have the choice of approaching customization
of xdvi as a TeX application or as an X application. Administrators
can place a texmf tree (such as /usr/local/share/texmf) in front of
/usr/share/texmf, or they can customize /etc/X11/app-defaults, or
both. Users can place a texmf tree (say $HOME/texmf) in front of
system trees, or they can customize ~/.Xresources, or both. And in
fact, there are some resources (e.g., mfMode) that are TeX-oriented,
and some (e.g., wwwBrowser) that are oriented more towards
compatibility with non-TeX system software. This observation confirms
the reasonableness of the goal of the xdvi wrapper to allow the option
to use a texmf-ASXRF. It also seems to me to be an argument against
the current behavior of the wrapper, which restricts administrators to
a single ASXRF in system directories: either the texmf-ASXRF or the
one in /etc/X11/app-defaults, but not both.
If the redundant symlink were to be deleted, and the wrapper were to
append texmf-ASXRFD to $XUSERSEARCHPATH, then the vanilla behavior
would be unaltered, but an administrator would have the IMPROVEMENT of
better choices: /usr/local/share/texmf/xdvi/XDvi could configure those
resources pertaining to the TeX installation, and
/etc/X11/app-defaults/XDvi could configure those resources specific to
the host. Moreover, the envariable $XFILESEARCHPATH regains its
usefulness as an analog to texmf.cnf, for choosing a file other than
/etc/X11/app-defaults/XDvi for system-oriented configuration, without
affecting TeX-oriented configuration in the texmf-ASXRF.
Only one category of user would be negatively affected by this change:
one who heretofore BOTH explicitly set $XUSERFILESEARCHPATH AND used a
user-specific texmf.cnf that pointed to a custom texmf tree containing
a texmf-ASXRF. If there is even one such user in the world, he or she
is almost certainly a master of these concepts and able to accommodate
this change very easily (by prepending texmf-ASXRFD to XFILESEARCHPATH
as the existing wrapper does -- or most surely by migrating to the
more powerful resource-database system, which remains available, just
as before, to both users and administrators.)
It seems far more likely that a user or sysadmin is going to introduce
a new texmf-ASXRF (i.e. not /usr/share/texmf/xdvi/XDvi), such as from
a TeXLive CD-ROM or an exported departmental texmf tree, than to go
messing with XFILESEARCHDIR or XUSERFILESEARCHDIR. As long as this is
more often the case, the proposed change to the wrapper brings another
IMPROVEMENT to the accuracy of information reported by appres(1),
which necessarily resources assigned by the texmf-ASXRF because it
doesn't and can't know about that file.(*) In this situation, appres
will report the values assigned in the system-ASXRF, but xdvi will not
see them, seeing only those values that are defined in the
texmf-ASXRF. (This baffling situation is, by the way, how I became
motivated to figure out this whole mess.) If you have a
/usr/local/share/texmf/xdvi/XDvi that defines just one resource -- or
even NO resources -- the simple fact that this file exists causes the
system to ignore EVERYTHING in /etc/X11/app-defaults/XDvi. What's
more, appres reports every setting in the latter, and no settings in
the former. Suppose I set "mfMode" in the (non-vanilla) texmf-ASXRF
and "background" to "yellow" in /etc/X11/app-defaults/XDvi. Appres
will report that the background resource is "yellow", but regardless
of the apparent value of this resource, the background will in fact
always be white (the compiled-in default). With the change I propose,
bafflingly incorrect output from appres will only be displayed to
users who have messed with BOTH X-windows AND TeX configuration and
thus can be expected to know more what they are doing.
(*) Well, I think the appres problem could be fixed completely, but
it would be a lot of work for little gain. A lot of gain for a
little work would be the IMPROVEMENT of documenting in both the xdvi
manual page and the comments in the script itself how to invoke
appres so that it will always give accurate information:
% XUSERFILESEARCHPATH="$XUSERFILESEARCHPATH:`kpsewhich -progname=xdvi --format='other text files' XDvi`" appres XDvi
Which of course could be bundled into a shell function or script:
appres_xdvi () {...}
And meanwhile submitting a documentation bug upstream to the
maintainers of the X(1) page.
The complete solution would I think involve some kind of manual
merging of the current texmf-ASXRF with the default system-ASXRF,
storing it in /var/lib/texmf/xdvi/XDvi and putting a symlink in
/etc/X11/app-defaults pointing to it. A real pain, involving
probable modification of mktexlsr, update-*, and so on.
Here are the changes to the wrapper. Please check my Perl! I don't
usually do Perl.
cd /usr/local/share/scripts/
diff -u /usr/bin/xdvi /usr/local/share/scripts/xdvi
--- /usr/bin/xdvi 2004-03-04 18:35:57.000000000 -0500
+++ /usr/local/share/scripts/xdvi 2004-05-06 01:31:24.000000000 -0400
@@ -16,7 +16,7 @@
# we need to modify XAPPLRESDIR. If you are running R4 or later, you
# can set XUSERFILESEARCHPATH for user specific application default
# files. You cannot use XAPPLRESDIR for user specific application default
-# files.
+# files when using R3.
# Julian writes:
# While Debian runs X11R6, we keep the XAPPLRESDIR part of the code for
@@ -39,21 +39,53 @@
$ENV{'XDVIINPUTS'} .= ":\$TEXMF/{xdvi,web2c}";
-my ($xdviappfile, $xdviappdir, $xdviapppath);
+my ($xdviappfile, $xdviappdir, $xdviapppath, $xhome, $xrealhome);
$xdviappfile=`kpsewhich -progname=xdvi --format='other text files' XDvi`;
if ("$xdviappfile" ne '') {
$xdviappdir=dirname($xdviappfile);
$xdviapppath="$xdviappdir/%N";
- # For R3, we have to set XAPPLRESDIR.
- $ENV{'XAPPLRESDIR'}=$xdviappdir;
+ # Perhaps this can be simplified: help me, I don't know Perl well!
+ if (exists $ENV{'XAPPLRESDIR'}) {
+ $xhome=$ENV{'XAPPLRESDIR'};
+ $xrealhome=$ENV{'HOME'};
+ } else {
+
+ # Can we assume HOME exists? Works OK when I invoke xdvi with
+ # a null HOME, but I haven't pounded on this or figured it out
+ # theoretically.
+ $xhome=$ENV{'HOME'};
+ $xrealhome=$ENV{'HOME'};
+ }
- # For R4 or later, we have to set XFILESEARCHPATH, since XAPPLRESDIR might
- # be ignored (if XUSERFILESEARCHPATH is set)
- if (exists $ENV{'XFILESEARCHPATH'}) {
- $ENV{'XFILESEARCHPATH'} = "$xdviapppath:$ENV{'XFILESEARCHPATH'}";
+ # We set XAPPLRESDIR for R3. It will be ignored by R4 because
+ # XUSERFILESEARCHPATH will be set explicitly.
+ # Note: $XAPPLRESDIR should end with a / for POSIX compliance (search for
+ # POSIX in man X(1)).
+ $ENV{'XAPPLRESDIR'}="$xdviappdir/";
+
+ # For R4 or later, we append to XUSERFILESEARCHPATH. If it was
+ # empty to start with, we furnish the default value explicitly,
+ # prior to our addition, for users who rely on the default value.
+ # We tamper with the default value as reported in man X(1) because
+ # we have tampered with the value of XAPPLRESDIR.
+ ##
+ # Note: X will load the first resource file in XUSERFILESEARCHPATH
+ # and the first resource file in XFILESEARCHPATH, if they exist.
+ # Values defined in the first file will override ones defined in
+ # the second. These facts appear not to be documented in man X(1)
+ # on a 5 May 2004 Debian "testing" system. X resources defined in
+ # the environment (i.e., xrdb) and on the command-line will
+ # override values defined in the application-specific resource file.
+ ##
+ # Note: to use appres(1) to determine what resources xdvi will
+ # use, use the command:
+ # XUSERFILESEARCHPATH="$XUSERFILESEARCHPATH:`kpsewhich -progname=xdvi --format='other text files' XDvi`" appres XDvi
+
+ if (exists $ENV{'XUSERFILESEARCHPATH'}) {
+ $ENV{'XUSERFILESEARCHPATH'} = "$ENV{'XUSERFILESEARCHPATH'}:$xdviapppath";
} else {
- $ENV{'XFILESEARCHPATH'} = $xdviapppath;
+ $ENV{'XUSERFILESEARCHPATH'} = "$xhome/%L/%N%C:$xhome/%l/%N%C:$xhome/%N%C:$xrealhome/%N%C:$xhome/%L/%N:$xhome/%l/%N:$xhome/%N:$xrealhome/%N:$xdviapppath";
}
}
Diff finished at Thu May 6 01:31:48
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.6.5-beth.4
Locale: LANG=en_US, LC_CTYPE=en_US
Versions of packages tetex-bin depends on:
ii debconf 1.4.22 Debian configuration management sy
ii debianutils 2.8.1 Miscellaneous utilities specific t
ii dpkg 1.10.20 Package maintenance system for Deb
ii ed 0.2-20 The classic unix line editor
ii libc6 2.3.2.ds1-12 GNU C Library: Shared libraries an
ii libgcc1 1:3.3.3-6 GCC support library
ii libice6 4.3.0-7 Inter-Client Exchange library
ii libkpathsea3 2.0.2-10 path search library for teTeX (run
ii libpaper1 1.1.14 Library for handling paper charact
ii libpng12-0 1.2.5.0-6 PNG library - runtime
ii libsm6 4.3.0-7 X Window System Session Management
ii libstdc++5 1:3.3.3-6 The GNU Standard C++ Library v3
ii libt1-5 5.0.2-0pre1 Type 1 font rasterizer library - r
ii libwww0 5.4.0-9 The W3C WWW library
ii libx11-6 4.3.0-7 X Window System protocol client li
ii libxaw7 4.3.0-7 X Athena widget set library
ii libxext6 4.3.0-7 X Window System miscellaneous exte
ii libxmu6 4.3.0-7 X Window System miscellaneous util
ii libxt6 4.3.0-7 X Toolkit Intrinsics
ii mime-support 3.26-1 MIME files 'mime.types' & 'mailcap
ii perl 5.8.3-3 Larry Wall's Practical Extraction
ii sed 4.0.9-2 The GNU sed stream editor
ii tetex-base 2.0.2-6 Basic library files of teTeX
ii xlibs 4.3.0-7 X Window System client libraries m
ii zlib1g 1:1.2.1-5 compression library - runtime
-- debconf information:
* tetex-bin/hyphen:
tetex-bin/oldcfg: true
* tetex-bin/upd_map: true
tetex-bin/cnf_name:
* tetex-bin/fmtutil: true
* tetex-bin/use_debconf: true
* tetex-bin/groupname: users
* tetex-bin/userperm: false
* tetex-bin/groupperm: true
* tetex-bin/lsr-perms: true
* tetex-bin/texmf: true
--- End Message ---