[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: proposal: 'xterm' alternatives entry

Jay Berkenbilt <ejb@ql.org> wrote:

>>   > The procedure would be to upload a new 'xterm' package which moves
>>   > /usr/bin/xterm to /usr/bin/xterm.real and introduces /usr/bin/xterm

> Of course, you mean /usr/X11R6/bin/xterm...

I didn't notice that.  Though the cygwin people have been moving everything
out of /usr/X11R6 for some reason...

>>   Mandrake did something like that a while ago(*) - broke the
>>   application name for X resources.

> I was also going to point out the issue of X resources.  While
> remaining in favor of fixing other applications rather than changing
> xterm, I would point out that this issue could be mitigated by having
> xterm be moved into another directory so its base name would be the
> same.  (I suppose /usr/lib/xterm/xterm could work...)  That said, I am

That probably would work.  It's only the argv[0] that's used to get the
application name, iirc.

> not able to convince myself that this is an issue here... if I clear
> my X resources, set HOME to a temporary directory, copy
> /usr/X11R6/bin/xterm (as root, preserving setuid) to /tmp/xterm.real,
> and invoke /tmp/xterm.real, I see a client class of UXTerm and a
> client name of xterm.  Maybe this is debian-specific?  I thought only
> uxterm did that.

I thought so too - uxterm passes the "-class" option for this purpose.
And that's one of the few that isn't implemented using a resource value,
so it's unlikely that your xrdb setup could pass a -class option to it.
(Usually I'm running whatever xterm I compiled - from /usr/local/bin -
but should have noticed if Debian had modified that - was testing on

Thomas E. Dickey

Reply to: