.Xresources vs. .Xdefaults (vs. xterm geometry)

[Ivan Shmakov]

>>>>> Grant Taylor <gta...@tnetconsulting.net> writes:
>>>>> "P" == pedr...@lycos.com writes:

[Cross-posting to news:comp.windows.x.]

[...]

>> Is there some other configuration file that might work?

> I'm not sure of the relationship between ~/.Xdefaults and
> ~/.Xresources and any variant of the two.

The difference is that ~/.Xdefaults is read by libXt-based
programs (such as XTerm) each time one is started, whereas
.Xresources is read by xrdb(1), typically once during user
session initialization (from /etc/X11/Xsession or the like.)

As such, after .Xresources is changed, it's necessary to use
$ xrdb -merge < ~/.Xresources for the changes to take effect.

The difference between the approaches also shows when X clients
come from different hosts. Suppose that I start XTerm's from
three remote hosts, like:

$ dsh -c --machine=foo,bar,baz -- uxterm &

There (assuming $HOME is /not/ shared), each XTerm will read
~/.Xdefaults from its own host, while only one copy of Xrdb data
will be read by them all from the X server itself -- as loaded
there by xrdb(1). When such a setup is used, maintaining a single
~/.Xresources file on whatever host the X session is started on may
come more convenient than maintaining a bunch of ~/.Xdefaults files.

Not to mention that Xrdb is easier to experiment with, IMO; like:

$ printf %s\\n "XTerm.vt100.geometry: 80x32" | xrdb -merge

> There is a chance that XTerm is being started with a different -name
> value. This means that it will be looking for <thatName>*geometry.
> I do this to have different configurations for different programs in
> XTerm. I. e.

> myProgram.vt100.geometry: 80x25 myProgram.vt100.font: 10x20
> myProgram.vt100.utf8Fonts.font: 10x20

That's apparently the case, per [1]:

P> The ancient program launches xterm with a command like this:

P> sh -c xterm -name fubar -T title -n app

In such a case, indeed, the resource to set should be either
fubar.vt100.geometry: /or/ XTerm.vt100.geometry: -- with the
'XTerm' /class/ name (that can be changed separately with -class)
used instead of the 'fubar' instance name (set with -name.)

[1] news:db4cccd4-a2c6-4a87...@googlegroups.com

--
FSF associate member #7257 http://am-1.org/~ivan/

[Javier]

Ivan Shmakov <iv...@siamics.net> wrote:
> As such, after .Xresources is changed, it's necessary to use
> $ xrdb -merge < ~/.Xresources for the changes to take effect.

> Not to mention that Xrdb is easier to experiment with, IMO; like:
>
> $ printf %s\\n "XTerm.vt100.geometry: 80x32" | xrdb -merge
>

To do experiments the sanest is to use the -xrm command line option,
which is valid for any program that uses Xresources.

xterm -xrm "XTerm.vt100.geometry: 80x32" [1]

If the experiment fails the experimental setting is gone.
If the experiment succeds you add the line to ~/.Xresources
or ~/.Xdefaults [2]

With 'xrdb -merge' you need to remember to unset later the failed
'experiments'. Otherwise the 'experimental' settings stay there until
you close all X clients and restart the X session.

This happens when you delete a line in ~/.Xresources and you do

xrdb -merge < ~/.Xresources

The 'deleted' setting is still there, because you are doing a merge.


[1] Not the topic in the post, but let me remind that both X and T should
be uppercase in the class name.

xterm -xrm "XTerm.vt100.geometry: 80x32" # Correct
xterm -xrm "Xterm.vt100.geometry: 80x32" # Fails, and it is hard to guess why

[2] For simplicity in my $HOME dir .Xresources is a symlink to .Xdefaults

[Noel Hunt]

> > I'm not sure of the relationship between ~/.Xdefaults and
> > ~/.Xresources and any variant of the two.
>
> The difference is that ~/.Xdefaults is read by libXt-based
> programs (such as XTerm) each time one is started, whereas
> .Xresources is read by xrdb(1), typically once during user
> session initialization (from /etc/X11/Xsession or the like.)

There seems to be some misunderstanding about how xrdb works.
It reads no file by default, the user must supply a file as
argument, or make it available on stdin. Hence, the name of the
file is irrelevant; I think '.Xresources' was simply a convention.
I believe xrdb loads a special resource nameed 'RESOURCE_MANAGER'
into the X server and clients will read resouces from that, rather
than read files. Without this resource present, clients will read
from files (via the X11 libraries), in particular, the older method
of reading from the file '.Xdefaults'.

[Ivan Shmakov]

>>>>> Noel Hunt <noel...@gmail.com> writes:

I've missed this response as it wasn't cross-posted to
news:comp.os.linux.misc, where the thread originated.

FTR, I stand by my suggestion to /avoid/ using Go*gle Grou*s in
place of a proper newsreader for participating in Usenet
discussions, as it makes a really poor substitute.

>>> I'm not sure of the relationship between ~/.Xdefaults and
>>> ~/.Xresources and any variant of the two.

>> The difference is that ~/.Xdefaults is read by libXt-based programs
>> (such as XTerm) each time one is started, whereas .Xresources is
>> read by xrdb(1), typically once during user session initialization
>> (from /etc/X11/Xsession or the like.)

> There seems to be some misunderstanding about how xrdb works. It
> reads no file by default, the user must supply a file as argument, or
> make it available on stdin. Hence, the name of the file is
> irrelevant; I think '.Xresources' was simply a convention.

Yes. Which is the whole point of my observation above; were it
not a convention for /etc/X11/Xsession to pass this file to xrdb(1)
to read, it would be meaningless to have it in the first place.

> I believe xrdb loads a special resource named 'RESOURCE_MANAGER' into
> the X server and clients will read resources from that, rather than

> read files. Without this resource present, clients will read from
> files (via the X11 libraries), in particular, the older method of
> reading from the file '.Xdefaults'.

I wasn't aware that ~/.Xdefaults gets ignored when server-side X
resources are present, thanks.

That said, libXt applications will still (try to) read
.Xdefaults-${HOSTNAME} -- and, of course, whatever appropriate
under XAPPLRESDIR, HOME, or /etc/X11/app-defaults; consider, e. g.:

$ strace -- xlogo 2>&1 | grep -F -- "$HOME"
...
open("/home/private/users/ivan/.Xdefaults-sydabo.siamics.net", O_RDONLY) = -1 ENOENT
access("/home/private/users/ivan/.app-defaults/eo.UTF-8/XLogo", R_OK) = -1 ENOENT
access("/home/private/users/ivan/.app-defaults/eo/XLogo", R_OK) = -1 ENOENT
access("/home/private/users/ivan/.app-defaults/XLogo", R_OK) = -1 ENOENT
access("/home/private/users/ivan/XLogo", R_OK) = -1 ENOENT
access("/home/private/users/ivan/.app-defaults/eo.UTF-8/XLogo", R_OK) = -1 ENOENT
access("/home/private/users/ivan/.app-defaults/eo/XLogo", R_OK) = -1 ENOENT
access("/home/private/users/ivan/.app-defaults/XLogo", R_OK) = -1 ENOENT
access("/home/private/users/ivan/XLogo", R_OK) = -1 ENOENT

[Grant Taylor]

On 4/10/19 8:40 AM, Ivan Shmakov wrote:
> FTR, I stand by my suggestion to /avoid/ using Go*gle Grou*s in place
> of a proper newsreader for participating in Usenet discussions, as it
> makes a really poor substitute.

Agreed.

Not the least of which is that some (text only) news server operators
filter Go*gle Grou*s. From the flip side is that Go*gle Grou*s doesn't
carry all the newsgroups that are available on Usenet. IMHO, this means
that Go*gle Grou*s is a poor substitute for a real Usenet NNTP server
and associated reader.

> I wasn't aware that ~/.Xdefaults gets ignored when server-side X resources
> are present, thanks.
>
> That said, libXt applications will still (try to) read
> .Xdefaults-${HOSTNAME} -- and, of course, whatever appropriate under
> XAPPLRESDIR, HOME, or /etc/X11/app-defaults; consider, e. g.:

That explains a behavior I saw on a workstation I used at my last job.



--
Grant. . . .
unix || die