Jay Berkenbilt <[EMAIL PROTECTED]> 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 Friday). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net