Working around an irritating recent XTerm change in behavior
Suppose, not hypothetically, that you
have just performed an operating system upgrade that upgraded the
xterm. On the surface, this version of
just like the old one; for example, your default
xterm looks like
this, which is normal and how it used to.
However, you also have 'root xterms' for your
su sessions, with
a red foreground to make them stand out as special (cf). When you call one of these up for
the first time, it looks like this.
That obtrusive, ugly black border doesn't belong there, and it
didn't used to be there in older versions of
xterm (and this is
not a window manager decoration;
xterm draws it itself, inside
any window manager framing). This border appears because of a change
in xterm patch #334:
- color the inner border using the same
borderColoras the outer border, rather than filling with the VT100's default background.
What this innocent sounding change appears to do is colour this inner border in your default foreground colour, whatever that is (black, in my case, since my default xterm colours are black on white), unless you are using entirely default colours. The moment you set any or all of foreground, background, or cursor colour, you get the border drawn in. In xterm patch #334 (which is the version in Fedora 29), the only way to avoid this is to explicitly set the border colour to your background colour, whatever that is for any particular xterm.
(The border colour may be set with either the
resource or the
-bd command line argument. Which one you use
depends on how you're changing the other colours; for my sins, I
have a mixture, so I get to make changes all over.)
In xterm patch #335, this
behavior was effectively reversed (as far as I can tell), although
the patch notes will not tell you that. Instead you need to consult
the xterm manpage, which now
says that by default
xterm is back to filling the inner border
with the background color and you can set the
resource to change that. Of course, the default xterm resources
that your Unix ships may be altered to change this; if they are,
you will need to change things back to restore the old default
The good news is that patch #335 came out only a few days after patch #334. The bad news is that xterm #334 made it into at least one Unix (specifically, Fedora 29). Hopefully your Unix will skip past #334, and also hopefully it won't pick a version of xterm that has other surprises.
As a look at the xterm changelog will show you,
xterm undergoes a lot more change than you might expect in such
an old and venerable program (certainly more change than I expect,
at least). Some of these changes are fixes for bugs and issues,
and some of them are useful improvements, but every so often there
are things like this change that make me less than happy.
(There was the xterm patch #301 change to
$SHELL handling in 2015, for example, which was later recognized
as flawed and augmented with the
validShells X resource in xterm
patch #334. Yes, the same patch that added this new behavior.
The irony is thick.)
PS: It is worth looking at the
XTerm default X resources file
that your Unix provides along with its
xterm, because historically
various packagers and distributors have been unable to keep their
hands off it. The upstream
XTerm default resources have been
quite stable over the years, a stability that's appreciated by
xterm users like me; distribution ones, not so much.