* Andy Saxena (andyML@nyc.rr.com) [020508 18:44]:
> Even if an executable can tell whether or not it is being called by a
> symlink, why should the xterm binary be coded to disregard the
> ~/.Xresources file?
Well, technically speaking, xterm never reads the .Xresources file at
all. That file is read by the X server at login time to set entries in
the X server resource database. You can also use the xrdb utility to
set, change, and remove these entries.
When xterm is run, it queries this database for certain values; things
like font size, background color, etc. Basically, for each variable, it
goes through this process:
Was the value given on the command line?
Yes => Use this value
No => Is there an entry in the X resource database?
Yes => Use this value
No => use the default value
The X resources generally look like "applicationName*attribute: value"
When you start an xterm, queries to the resource database are made for
xterm's "name" where I've written "applicationName" above. This name is
given by either the command line argument "-name foo" or by looking at
argv[0]. So when you use a symlink with a different name, argv[0] is
different, and so therefore is the default name by which resources are
loaded.
> How does that help?
It allows for the possibility of having different attribute sets for
different-behaving xterms. For example, I have one which I call with
"-name xterm-mutt" which starts out with a larger window and no scroll
bars. I also have a different-named xterm which starts out with larger
fonts, for when other people use my computer and ask ""Jeez! How can you
read that small text!?"
Forgive me if I've been loose and quick with this explanation. A more
detailed explanation of X resources is given in X(7).
good times,
Vineet
--
Currently seeking opportunities in the SF Bay Area
Please see http://www.doorstop.net/resume.shtml
Attachment:
pgp4jcbJoa9SV.pgp
Description: PGP signature