Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
.Xresources and xterm size
489 views
Skip to first unread message
pedr...@lycos.com
Mar 26, 2019, 8:39:32 AM3/26/19
to
I have an old package using xterm. It opens xterm without any geometry
options. I found somewhere that you can change default size
if you create a file
~/.Xresources
with a line like this:
xterm*geometry: 132x80
I tried this in Centos 6, but it has no effect.
Is there some other configuration file that might work?
options. I found somewhere that you can change default size
if you create a file
~/.Xresources
with a line like this:
xterm*geometry: 132x80
I tried this in Centos 6, but it has no effect.
Is there some other configuration file that might work?
Bit Twister
Mar 26, 2019, 9:12:38 AM3/26/19
to
$ grep geometry .X*
.Xdefaults:Vim*geometry: 88x35
.Xresources:emacs.geometry: 80x25
Might suggest you need to verify that $TERM is xterm to match your
declaration.
Fenris
Mar 26, 2019, 12:50:02 PM3/26/19
to
Jean-David Beyer
Mar 26, 2019, 2:06:55 PM3/26/19
to
program:
!COMMENT Lines starting with xosview are for xosview program.
!
xosview*geometry: 611x562+658+512
xosview*loadloadPriority: 10
xosview*loadWarnThreshold: 4
xosview*pageBandwidth: 250
xosview*pagePriority: 10
xosview*pageIdleColor: grey
xosview*pageInColor: green
xosview*pageOutColor: red
xosview*cpuPriority: 10
xosview*cpuFreeColor: grey
xosview*diskIdleColor: grey
xosview*diskReadColor: green
xosview*diskWriteColor: red
xosview*diskUsedFormat: autoscale
xosview*net: True
xosview*netInColor: green
xosview*netOutColor: red
xosview*netBackground: grey
xosview*netBandwidth: 9375000
xosview*netPriority: 10
xosview*netUsedFormat: autoscale
xosview*intPriority: 3
--
.~. Jean-David Beyer
/V\ PGP-Key:166D840A 0C610C8B
/( )\ Shrewsbury, New Jersey
^^-^^ 14:00:01 up 2 days, 11 min, 3 users, load average: 5.31, 5.34, 4.88
Bit Twister
Mar 26, 2019, 3:07:07 PM3/26/19
to
Then again I would have been using -merge while testing.
Example:
xrdb -merge ~/.Xdefaults
Note: Supposedly .Xresources is used/sourced once during login
and .Xdefaults is sourced on each xterm launch.
Which is why I have the bulk of changes in .Xresources
$ sort -u .Xdefaults | grep -v '!!' | wc -l
19
$ sort -u .Xresources | grep -v '!!' | wc -l
131
Grant Taylor
Mar 26, 2019, 6:55:47 PM3/26/19
to
On 3/26/19 6:39 AM, pedr...@lycos.com wrote:
> I have an old package using xterm. It opens xterm without any geometry
> options. I found somewhere that you can change default size
> if you create a file
> ~/.Xresources
> with a line like this:
> xterm*geometry: 132x80
>
> I tried this in Centos 6, but it has no effect.
I want to say that I had an issue with RHEL6 (effectively the same
> I have an old package using xterm. It opens xterm without any geometry
> options. I found somewhere that you can change default size
> if you create a file
> ~/.Xresources
> with a line like this:
> xterm*geometry: 132x80
>
> I tried this in Centos 6, but it has no effect.
thing) where I had to have ~/.Xdefaults.$HOSTNAME. I just created a
sym-link to my ~/.Xdefaults file. (At least that's what I remember.)
> Is there some other configuration file that might work?
and any variant of the two.
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
Then I open the program with "xterm -name myProgram -e /path/to/myProgram"
This allows myProgram to run in an 80x25 window with a bigger font than
my default XTerm windows.
xterm.vt100.geometry: 132x50
--
Grant. . . .
unix || die
Jean-David Beyer
Mar 26, 2019, 8:44:37 PM3/26/19
to
On 3/26/19 6:55 PM, Grant Taylor wrote:
>> I tried this in Centos 6, but it has no effect.
I am running Red Hat Enterprise Linux Server release 6.10 (Santiago)
>> I tried this in Centos 6, but it has no effect.
that should be as close to CentOS 6 as one can get.
>
> I want to say that I had an issue with RHEL6 (effectively the same
> thing) where I had to have ~/.Xdefaults.$HOSTNAME.
I do not need .$HOSTNAME. IN THE .Xdefaults file.
> I want to say that I had an issue with RHEL6 (effectively the same
> thing) where I had to have ~/.Xdefaults.$HOSTNAME.
--
.~. Jean-David Beyer
/V\ PGP-Key:166D840A 0C610C8B
/( )\ Shrewsbury, New Jersey
Dan Espen
Mar 26, 2019, 8:51:04 PM3/26/19
to
work at all.
This is what I use, it works:
XTerm*vt100*geometry: 80x34
To see what resources are currently active do:
apress XTerm
You can reload xresources at any time, no need to restart anything but
xterm. Test your changes with:
xrdb -load ~/.Xresources
at a command line to make sure there are no syntax errors.
--
Dan Espen
Dan Espen
Mar 26, 2019, 8:55:52 PM3/26/19
to
Jean-David Beyer <jeand...@verizon.net> writes:
> On 3/26/19 6:55 PM, Grant Taylor wrote:
>>> I tried this in Centos 6, but it has no effect.
>
> I am running Red Hat Enterprise Linux Server release 6.10 (Santiago)
> that should be as close to CentOS 6 as one can get.
>>
>> I want to say that I had an issue with RHEL6 (effectively the same
>> thing) where I had to have ~/.Xdefaults.$HOSTNAME.
>
> I do not need .$HOSTNAME. IN THE .Xdefaults file.
You can do a limited amount of conditional logic in an xrdb file.
> On 3/26/19 6:55 PM, Grant Taylor wrote:
>>> I tried this in Centos 6, but it has no effect.
>
> I am running Red Hat Enterprise Linux Server release 6.10 (Santiago)
> that should be as close to CentOS 6 as one can get.
>>
>> I want to say that I had an issue with RHEL6 (effectively the same
>> thing) where I had to have ~/.Xdefaults.$HOSTNAME.
>
> I do not need .$HOSTNAME. IN THE .Xdefaults file.
From one of mine:
#if ( HEIGHT == 2160 )
XTerm*font: lucidasanstypewriter-bold-24
#else
XTerm.font: -misc-liberation mono-bold-r-normal--0-0-0-0-m-0-iso8859-1
#endif
The xrdb man page talks about the variables available.
--
Dan Espen
T
Mar 26, 2019, 9:04:18 PM3/26/19
to
Not what you asked, but I just stick what I want in the
run string and have a launcher for each size and color.
Here are some examples:
xterm4 10x20 Blue
xterm -fn 10x20 -fg blue -bg white -bdc -cc "33:48,37:48,45-47:48,38:48"
xterm4 8x16 Blue
xterm -fn 8x16 -fg blue -bg white -bdc -cc "33:48,37:48,45-47:48,38:48"
-geometry 140x25
xterm4 8x16 Green Clipboard
xterm -fn 8x16 -fg darkgreen -bg white -bdc -cc
"33:48,37:48,45-47:48,38:48" -geometry 140x25 -xrm
'*VT100*translations: #override \n Shift Ctrl <Key>C:select-end(PRIMARY,
CLIPBOARD, CUT_BUFFER0) \n Shift Ctrl <Key>V:insert-selection(PRIMARY,
CUT_BUFFER0)'
-T
pedr...@lycos.com
Mar 27, 2019, 6:48:22 AM3/27/19
to
On Wednesday, March 27, 2019 at 9:04:18 AM UTC+8, T wrote:
The ancient program launches xterm with a command like this:
sh -c xterm -name fubar -T title -n app
I am guessing that this does not cause .Xresources to be read.
I will try adding explicit geometry options
sh -c xterm -name fubar -T title -n app
I am guessing that this does not cause .Xresources to be read.
I will try adding explicit geometry options
Ivan Shmakov
Mar 27, 2019, 10:10:36 AM3/27/19
to
>>>>> 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/
>>>>> "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.
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
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
Mar 27, 2019, 11:03:27 AM3/27/19
to
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.
> 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,
>
> $ printf %s\\n "XTerm.vt100.geometry: 80x32" | xrdb -merge
>
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
Grant Taylor
Mar 27, 2019, 12:23:25 PM3/27/19
to
On 3/27/19 4:48 AM, pedr...@lycos.com wrote:
> The ancient program launches xterm with a command like this:
>
> sh -c xterm -name fubar -T title -n app
>
> I am guessing that this does not cause .Xresources to be read.
I think XTerm (et al.) read settings form the X environment.
> The ancient program launches xterm with a command like this:
>
> sh -c xterm -name fubar -T title -n app
>
> I am guessing that this does not cause .Xresources to be read.
You need to update the X environment via the xrdb command.
> I will try adding explicit geometry options
One of the nice things about X is that multiple programs / invocations
can inherit settings from the X environment, when things are configured
properly. Said configuration is the toe stubber.
T
Mar 27, 2019, 1:53:08 PM3/27/19
to
/usr/share/X11/fonts/misc
They have changed -n to -e
Some examples:
xterm -fn 8x16 -fg darkgreen -bg white -bdc -cc
/var/log/messages"
xterm -fn 7x14 -fg darkgreen -bg white -bdc -cc
"33:48,37:48,45-47:48,38:48" -geometry 120x68+450+40 -e
"/home/linuxutil/GetUpdates.pl6 2>&1"
J G Miller
Mar 27, 2019, 8:02:02 PM3/27/19
to
On Wednesday, March 27th, 2019, at 10:23:23h -0600, Grant Taylor wrote:
> On 3/27/19 4:48 AM, pedr...@lycos.com wrote:
>> The ancient program launches xterm with a command like this:
>>
>> sh -c xterm -name fubar -T title -n app
>>
>> I am guessing that this does not cause .Xresources to be read.
>
> I think XTerm (et al.) read settings form the X environment.
It is a lot more complicated than that.
> On 3/27/19 4:48 AM, pedr...@lycos.com wrote:
>> The ancient program launches xterm with a command like this:
>>
>> sh -c xterm -name fubar -T title -n app
>>
>> I am guessing that this does not cause .Xresources to be read.
>
> I think XTerm (et al.) read settings form the X environment.
Programs which use X resources will check for properties
set in the X resource database (first I think) and will also
check for a file with the class name or possibly but probably not
the instance name in directories specified by the shell environment
variable XFILESEARCHPATH, or the directory specified by the shell
environmental variable XAPPLRESDIR, or the file specified by the
shell environmental variable XDEFAULTS.
Things can get even more complicated when display numbers and
screen numbers are thrown into the mix.
I can never remember the exact order of priority from memory,
except that XDEFAULTS wins over all other file settings,
so best to consult the X11 manual page.
The usual convention is to have a resources file named with
the class name, and then for that contain instance names.
In the above example for xterm. -name specified the instance
name "fubar" BUT "-n" specifies the *icon* name as app, that is
the string displayed on the icon when the icon is visible on
the desktop background eg with {c|v}twm, fvwm, olvwm, Windowmaker
and other similar style window manager.
Incidentally, you do not have to close all X clients and logout
to clear the X resource database, the command
xrdb -remove
Specific entries can be deleted with xrdb -remove property_name
xrdb -q will show all properties set.
J G Miller
Mar 27, 2019, 8:14:16 PM3/27/19
to
On Wednesday, March 27th, 2019, at 10:53:02 -0700, Todd wrote:
> You can find a list of those font sizes over at
> /usr/share/X11/fonts/misc
Newer version of xterm are built with fontconfig (xft) support
> You can find a list of those font sizes over at
> /usr/share/X11/fonts/misc
as well as being able to use the old X11 bitmap fonts with
specific fixed sizes.
So as fontconfig fonts are usually scalable over a range (and/or may
have rules defined in /etc/fonts for sizes including font aliasing
or not at those sizes) you can do eg
XTerm.VT100*faceName: Luxi Mono
XTerm.VT100*faceSize: 12.0
xterm-console.VT100*faceName: Luxi Mono
xterm-console.VT100*faceSize: 11.0
The command fc-list reveals what fontconfig fonts are available to
xft aware programs.
Rich
Mar 29, 2019, 5:28:58 PM3/29/19
to
pedr...@lycos.com wrote:
> The ancient program launches xterm with a command like this:
>
> sh -c xterm -name fubar -T title -n app
>
> I am guessing that this does not cause .Xresources to be read.
You are correct, note this blurb from the xterm man page:
> The ancient program launches xterm with a command like this:
>
> sh -c xterm -name fubar -T title -n app
>
> I am guessing that this does not cause .Xresources to be read.
-name name
This option specifies the application name under which
resources are to be obtained, rather than the default exe-
cutable file name. Name should not contain "." or "*" charac-
ters.
So this particlar xterm is looking for resources under the "fubar"
name. If you add resources to .Xresources under the name "fubar" then
they should get read and used by these xterm invocations.
0 new messages