__________________________________________________________________
http://invisible-island.net/xterm/
Copyright © 1997-2021,2022 by Thomas E. Dickey
__________________________________________________________________
Here is the latest version of this file.
XTerm – Frequently Asked Questions (FAQ)
* (top)
* What is XTerm?
* Who wrote XTerm?
* What is a VT220?
* What platforms does it run on?
* What is the latest version?
* What versions are available?
* Comparing versions, by counting controls
* How do I ...
* Frequent problems
* Known Bugs in XTerm and Look–alikes
* How do I build XTerm?
* How do I report bugs?
* Additional Information
* Ongoing/future work
What is XTerm?
From the manual page:
The xterm program is a terminal emulator for the X Window System. It
provides DEC VT102/VT220 and selected features from higher-level
terminals such as VT320/VT420/VT520 (VTxxx). It also provides
Tektronix 4014 emulation for programs that cannot use the window
system directly. If the underlying operating system supports
terminal resizing capabilities (for example, the SIGWINCH signal in
systems derived from 4.3bsd), xterm will use the facilities to
notify programs running in the window whenever it is resized.
That is, xterm (pronounced "eks-term") is a specific program, not a
generic item. It is the standard X terminal emulator program.
This FAQ presents various useful bits of information for both the
specific program as well as other programs that imitate it.
As a stylistic convention, the capitalized form is "XTerm", which
corresponds to the X resource class name. Similarly, uxterm becomes
"UXTerm".
Who wrote XTerm?
I've been working on xterm since early 1996 (see my changelog for
details).
But the program is much older than that:
* A Prehistory Perspective
* Looking for more perspective
* My involvement
* Focus of this FAQ
A Prehistory Perspective
A lot of people, cited at the bottom of the manual page wrote the
original xterm program, maintained by the X Consortium (later part of
The Open Group – I'm well aware of the distinction, but am citing when
the work was done, not who the current owner may be). There is no
changelog, and it is not clear who did what. Email from Jim Gettys
(September 1998) provides some background:
Cast of thousands...
To give a bit of history, xterm predates X!
It was originally written as a stand-alone terminal emulator for the
VS100 by Mark Vandevoorde, as my coop student the summer that X
started.
Part way through the summer, it became clear that X was more useful
than trying to do a stand alone program, so I had him retarget it to
X. Part of why xterm's internals are so horrifying is that it was
originally intended that a single process be able to drive multiple
VS100 displays. Don't hold this against Mark; it isn't his fault.
I then did a lot of hacking on it, and merged several improved
versions from others back in.
Notable improvements include the proper ANSI parser, that Bob
McNamara did.
The Tek 4010 support came from a guy at Smithsonian Astrophysical
Observatory whose name slips my mind at the moment.
Ported to X11 by Loretta Guarino.
Then hacked on at the X Consortium by uncounted people.
Email from Doug Mink (October 1999) provides more background:
I was checking out the newly revised AltaVista search engine to see
what was on the net about xterm, and I found your pages. I can add
to the FAQ in that I was the "guy at the Smithsonian Astrophysical
Observatory" Jim Gettys refers to. I am listed at the end of the man
page under authors. What happened was that I was hired by SAO (after
leaving the research staff at MIT) in October 1985 to write analysis
software for the Spacelab 2 Infrared Telescope which was to fly on
the Space Shuttle in 1985 less than six months after I was hired. I
came with a tar tape full of software I had written for Unix and
Tektronix terminals, but I was presented with a VS100 terminal which
had an early version (X6 or so) of xterm, with no graphics
capabilities. SAO is at Harvard, across Cambridge from MIT, where
Jim Gettys was detailed from DEC to the X project, and Jim had
connections with SAO, having worked here after college (MIT, where
we had both worked at the observatory at various times); he was
still sharing an apartment with an SAO colleague of mine, too.
Anyway, everyone decided that since I knew Tektronix commands pretty
well, and our group desparately needed the graphics capabilities, it
would be a good use of my time to implement a Tektronix terminal
emulator under X. So I set to work learning more C--I had only
written a couple of wrappers to C I/O routines so I could use them
with my Fortran software--and wrote a Tektronix emulator. The only X
documentation at the time was the code itself. While I was at it, I
wrote an improved Tektronix emulator for our Imagen laser printer
which used the full resolution of that 300 dpi printer instead of
the effective 100 dpi (i.e. jaggy) emultator distributed with the
printer. The original xterm Tek emulator shared a window with the
VT100 emulator, much like on the VT240 terminals which I had been
using at MIT before I came to Harvard. With a VAX 750 running
several VS100's, window creation was sloowww, so sharing a window
was the quickest way to do things, and all of my software was
written for that mode of operation, anyway. While I wrote the
emulator so that my software would work on it, it was tested by the
X group against a BBN graphics package, the name of which slips my
mind right now.
Anyway, 15 years later, I am still using xterm and some of the same
mapping software I wrote the emulator for. And I am still at the
Smithsonian Astrophysical Observatory.
Looking for more perspective
VS100 refers to the VAXstation 100, introduced by DEC in 1984 (see
manual).
There is a git repository here which gives some more of xterm's
prehistory. But it has no usable data for X10 (see initial revisions in
1985/1986). The X developers did not really start checking in their
code until 1987.
The earliest version of xterm which is available is from X10R3.
According to the xc-historical repository, that was February 1, 1986 (a
change to the rgb.c file). Even that date is suspect because the X10R3
tarball contains xterm files later than that date:
17024 May 17 1986 xterm/util.c
31545 May 17 1986 xterm/main.c
1377 Feb 10 1986 xterm/Makefile
10804 Feb 3 1986 man/xterm.1
660 Feb 2 1986 xterm/terminfo
606 Feb 2 1986 xterm/termcap
1178 Feb 2 1986 xterm/tabs.c
10525 Feb 2 1986 xterm/screen.c
2907 Feb 2 1986 xterm/resize.c
6699 Feb 2 1986 xterm/ptyx.h
2720 Feb 2 1986 xterm/input.c
2959 Feb 2 1986 xterm/esctable.h
4482 Feb 2 1986 xterm/cursor.c
7661 Feb 2 1986 xterm/chartable.h
23543 Feb 2 1986 xterm/charproc.c
13990 Feb 2 1986 xterm/button.c
1122 Feb 2 1986 xterm/buf.c
3932 Feb 2 1986 xterm/ansi.c
15662 Feb 2 1986 xterm/Tplot.c
2382 Feb 2 1986 xterm/README
234 Feb 2 1986 cursors/xterm_mask.cursor
234 Feb 2 1986 include/X/cursors/xterm_mask.cursor
261 Feb 2 1986 cursors/xterm.cursor
261 Feb 2 1986 include/X/cursors/xterm.cursor
1335 Dec 21 1985 xterm/icon.ic
1350 Dec 21 1985 xterm/icon_mask.ic
But since the X10R3 tarball contains only 10 “later” files out of 974,
the 3-4 xterm files are just some after-the-fact correction whose
reason is long lost.
A posting by Andreas Motl to nfo.links.computing in March 2003
recapitulates the content of a page Linux desktops (GUIs, widgets,
window managers, etc) (Jorn Barger, November 2002). That mentions X10
(e.g., “X v10”):
1985: Sep: X v9 distributed as free [cite] cf Andrew [Gettys]
1985: X/Open Portability Guide [cite]
1985: Oct: Amiga 1.0 [info]
1985: 20Nov: Windows 1.0 ships [tour]
1985: Dec: Clayton Elwell's Portable User Interface Library project [GooJa]
1985: Dec: X v10r2 [annc]
"X is a portable network transparent window system for bitmap displays.
Applications can be run from any machine in a local area network via stream
connections (currently TCP and Unix domain are supported). X is a fully
hierarchic window system intended to be very flexible. Manipulation of existing
windows is done with an external window manager; if you don't like ours, write
your own. Applications include a terminal emulator (~VT102 and Tek 4010), load
monitor, clock, imagen previewer, and several window managers among other
things."
no-date: Windows 2.0 clones Mac interface; withdrawn and tweaked to avoid
lawsuit? [cite]
1986: Jan: DEC announces VAXstation with X
1986: Feb: X v10r3 [annc]
September 1985 might be accurate for X version 9. However, the first
line of the xterm manual page from X10R3 says
.TH XTERM 1 "1 January 1985" "X Version 10"
Jim Gettys might be able to explain that. Several of the files in that
version of xterm have copyright dates from 1984, making that the likely
beginning of development for xterm. Other parts of the X10R3 source
tree have similar clues. For example, Xlib may have begun development
in 1984, but since it was unreleased until the end of 1985, the actual
date is indeterminate.
A comment by Jim Fulton on slashdot in 2000 gives more details on the
early versions of X:
There weren't really ten full releases prior to X11R1, however there
were 10 incompatible revs of the protocol. Most of the early
versions were primarily used within MIT (Athena and LCS) and
friendly commercial R&D labs. Here's some of the pre-history based
on cryptic notes and blurry memory: X1 - summer 1984 - the first
version, based on a substantial rearchitecting of the UNIX port of
the W Window System (originally developed for the V Kernel). X3 -
fall 1984 - used internally at MIT as the initial basis of various
plotting packages for coursework. X6 - spring 1985 - first version
licensed by MIT to various companies (including Cognition, MASSCOMP,
and Digital) for use in commercial products. It cost $100 and if you
wanted you could stop off at the (very small) licensing office to
pick up your own magtape. X8/X9 - fall 1985 - added color (X8 lasted
all of about a week; X9 was quickly released to fix a protocol
alignment problem that impacted ports on the IBM PC/RT). Many
organizations began developing ports (including a version to the
Lexidata 9000 display card for VAXen that was used at the Autofact
tradeshow in late 1985 to show a prototype of the first 3rd party
application: a mechanical engineering design system). X.V10R1 -
spring 1986 - first version released by MIT that did not require
signing a license agreement. Also the first version to have a DOS
Xserver developed. X.V10R[234] - fall 1986 & spring 1987 - an
explosion of ports done on a variety of platforms. X.V11R1 - Sep 15,
1987 - major overall done in collaboration with folks from Digital,
Sun, IBM, and other companies. Formed the basis of core protocol
used today. Companies and organizations releasing X-based products
used this release as a starting port for incorporating into their
own distributions. X.V11R2 - March 1, 1988 - first version released
under the auspices of the newly-formed MIT X Consortium. The MIT X
Consortium continued to put out releases of X11 for a number of
years. Then in the mid-90s, it was spun off into a separate
not-for-profit organization (simple the X Consortium). As has been
noted, that eventually folded into various organizations that became
X.ORG. The rest is history. :) Jim Fulton
My Involvement
My involvement with xterm through XFree86 began at the end of 1995.
This website has been "here" since 2001/6/5, replacing my ClarkNet
page. I started the ClarkNet page 1996/12/31, as a followup to the
release of ncurses 4.0) which featured xterm as one of the 16 programs
I was involved with. From the outset, the page provided a link to a
snapshot of the current source. Copies of patches which I sent to
XFree86 were available on the ftp area.
XFree86 had its sources in CVS, but (like others in that era), were not
directly visible to random developers. That came later. I started by
downloading the sources (30Mb of compressed tar-files on a 56Kb phone
connection took about 6 hours) and updating them with patches from the
XFree86 mailing list.
Like the other programs that I worked on with others (vile, tin, lynx),
I set up an RCS archive to track my changes locally before sending
patches to the development list. As the XFree86 developers issued new
patches, I would re-synchronize my archive. Later, XFree86 provided CVS
(initially readonly). I was granted commit privileges on this in
November 2000, and stopped mailing patches after #149.
Throughout this period, my work on xterm was released as part of
XFree86. It was rare for a separate package to be provided. That was
due to the potential conflict between the install procedures. Users of
the downloads from my web/ftp site were predominantly individual
developers.
There were exceptions. Christian Weisgerber proposed a package for
FreeBSD ports later in 1999 (ports/15545: new port: x11/xterm, followup
in March 2000). However, that was an exception. None of the Linux
distributions provided a separate package before 2003 (when Mike Harris
created a package of patch #177 for Red Hat). Again that is more of an
exception than a rule:
* SuSE's package began October 23, 2004 with patch #196.
* Mandriva's package began October 22, 2005 with patch #205.
* The Debian package for xterm began in January 6, 2006 with patch
#204.
Given that context (sources distributed via XFree86 CVS, releases via
XFree86), the statement made by an Xorg hacker early in 2005 asserting
that “It has not been maintained by anyone within the XFree86 or X.org
trees for many years” was at best misleading.
After the “fork” (sic) of Xorg in 2004, I continued to commit changes
for xterm in XFree86 CVS until patch #216 in mid-2006. I stopped at
that point because it was not possible to incorporate changes into
xterm which were not sent to me first. I still send patch announcements
to both the XFree86 and Xorg mailing lists, of course.
At that point (mid-2006), the XFree86 CVS was no longer the primary
development repository for xterm. My RCS archive filled that need.
Later (starting in 2016), I provided Git snapshots using the RCS labels
which I make in development:
* Old xterm patches, from patch #1 through patch #149.
* Git snapshots, starting from xterm patch #41
Focus of this FAQ
This FAQ is oriented toward the version of xterm originally distributed
with XFree86 (more commonly known as modern, or "new xterm", with a
corresponding terminal description "xterm-new"), which was based on the
X11R6.3 xterm, with the addition of ANSI color and VT220 controls.
What is a VT220?
* Why a VT220?
* What is a State Table?
* Why not emulate VT320?
* Why emulate VT420?
* Why not emulate VT520?
Why a VT220?
The manual page mentions a VT220. Most terminal emulators documentation
talk about VT100. But a VT100 is a rather limited subset of what people
expect:
* VT100s have no function keys. Arguably, PF1-PF4 are function keys.
My keyboard has 12 function keys.
* VT100s do not do color.
Initially, I was only interested in making colors workable for curses
programs.
Later, I noticed that xterm had some support for what would now be
termed as ISO-2022. That was a VT220 feature which preceded ISO-2022
called National Replacement Character sets. In any case, it was not a
VT100 feature. There were some missing pieces. So I decided to fill in
those pieces and make xterm a VT220 emulator. (VT220s do not do ANSI
color either—the missing pieces were in other areas).
XTerm also provides features that are in neither VT100 nor VT220, which
are used by other programs as "xterm emulation".
* set (and retrieve) window- and icon-labels using escape sequences.
* interpret mouse clicks as escape sequences that can be read by a
program.
By the way, the control string used for setting the titles was not in a
standard format:
* In X10 (1988), the string was simply terminated by any nonprinting
character.
* X11R4 (1989) modified that to ensure that the nonprinting character
is an ASCII BEL (control/G).
* There is no explanation in the (sketchy) notes distributed with the
X11R4 xterm; in retrospect it seems that the most likely
explanation for the choice is that it was simpler to implement in
shell scripts than ESC \.
ECMA-48 (the standard) does not describe this particular control, but
prescribes its format (an operating system command). It does not use a
BEL.
I revised that area starting in 1996,
* first to use xterm's state table for handling the input, and then
* to accept the standard string terminator as well.
In addition to implementing the VT220's National Replacement Character
sets (see vttest screenshots), I added other features to emulate the
successive models of DEC terminals. The decTerminalID resource (in
1996) lets users select the emulation to use. Because many of my
changes were extensions (features not in any of DEC's terminals) and
because well-behaved VT100 applications would not use features from
higher-level terminals it was not initially important to prevent use of
those by applications which assumed they were using just a VT100.
Knowledgable users could easily configure xterm to emulate a VT220. In
2012, I changed the default from VT100 to VT420.
What is a State Table?
That was mentioned regarding the title strings. XTerm uses a state
machine to handle incoming characters. That is essentially what a real
terminal does. Other "xterm" terminal emulators typically do not do
this, which makes them not do well with vttest.
Why not emulate VT320?
You could do that (by changing decTerminalID, but the results were not
that interesting). In retrospect, the VT320 was a stopgap
implementation designed to bridge between the VT200 series and the
VT420. It provided a standard codepage (for ISO Latin-1).
While it had other features not found in the VT200-series, most of
those are less useful in a terminal emulator. I did adapt the ECMA-48
scrolling operations which the VT320 interpreted as panning the visible
display in the terminal's memory. Expect some difference there (if you
can find an application on VMS which used the feature).
The VT320 was popular with developers of commercial terminal emulators,
whose literature referred to it as supporting ANSI color. It did not do
this.
Why emulate VT420?
The VT420 was interesting because it provided two features that could
be useful:
* rectangles
* left/right margins (like the top/bottom scrolling margins)
A VT420, of course, supports all of the features in VT320, in turn all
of the features in VT220, and in turn VT100. Users would not lose
features by changing the default emulation to VT420. By changing the
default emulation, most users would automatically be able to use
applications (such as tmux) that could perform better if the left/right
margin feature is available. I changed the emulation to VT420 in 2012
for this reason.
XTerm does not emulate some esoteric features (such as dual sessions)
because those require hosts using special software, and no
publicly-available documentation was available.
Why not emulate VT520?
Again, the VT500-series is less interesting because most of the
features which are not hardware-specific (such as reporting
transmission rate) are less useful.
However:
* the VT500-series provides additional codepages (like the VT320).
XTerm does that.
* the VT500-series supports some of the ECMA-48 cursor-movement
operations which had been overlooked in the previous terminals.
XTerm does that (based on ECMA-48 itself, and later on DEC's
documentation).
As for the other features, most are not useful in emulation (since they
are hardware-specific). Additionally, these less-used features are not
documented precisely and since the only point of providing them would
be for successful interoperability with legacy applications, some
reverse-engineering would be needed to provide a faithful emulation. To
date there are no known terminal emulators which do that.
What platforms does it run on?
XTerm runs in all of the implementations of X11. As of 2000, I had
built and run these since I started working on xterm in 1996:
* AIX 3.2.5, 4.1, 4.3 (cc)
* Digital Unix 3.2, 4.0, 5.0 (cc)
* FreeBSD 2.2.6 to 6.0 (gcc 2.8)
* HP-UX 9.05 to 11.23 (gcc 2.7.2 to 3.4)
* IRIX 5.2, 6.2 (cc, gcc 2.7.2, gcc 2.8)
* Linux 2.0.0 to 2.6.26 (gcc 2.7.2 to 4.3)
* SCO OpenServer 5 (cc, gcc).
* Solaris 2.4, 2.5, 2.5.1, 2.6, 7, 8 (cc, gcc 2.7.2)
* SunOS 4.1.1, 4.1.3 (gcc 2.7.2)
The older configurations have X11R5 libraries. Only minor changes are
needed to make xterm work on those systems. However, X11R6 provided
better locale support, as well as new features such as the active icon.
X11R7... not much to say there.
Since 2000, there have been many changes (including new platforms such
as MacOS, NetBSD, OpenBSD, etc., as well as QNX, Cygwin, and Minix).
What is the latest version?
The most recent (and well supported) version of xterm is the one that I
maintain:
* source
* archives
What versions are available?
There are several other versions of xterm, based on xterm's source.
These include
* ansi_xterm
* color_xterm
* cxterm (Chinese)
* hanterm (Korean)
* mxterm
* nxterm
* kterm (Japanese)
* xterm (from X Consortium)
There are similar programs not based on xterm's source, which are
compatible to different degrees. These include
* dtterm
* emu (from X Consortium)
* Eterm
* GNOME Terminal
* Multi GNOME Terminal (MGT)
* mterm
* konsole
* mlterm (Multi Lingual)
* osso-xterm
* roxterm
* rxvt
* st
* xfce-term
* xgterm
* xiterm
Some of these use the VTE widget. Since that supplies most of the
terminal emulation, the remaining differences between programs using
VTE tend to be at the level of the window manager (menus, borders,
etc.). Other (older) programs which are based on reusable widgets
include dtterm and emu.
(I am aware of a few others, such as xcterm, but have not seen a
working version of these).
Finally of course, there are a multitude of programs which set TERM to
"xterm", in the hope that applications will treat them the same as
xterm. For example,
* PuTTY does this (see its FAQ A.5.1 What terminal type does PuTTY
use?). But its wrapping behavior is incompatible with xterm (and
any vt100 emulator). You can see this in the first menu entry for
vttest.
* VTE does this. But consider the list of problems with VTE and with
GNOME Terminal. The attitude of the developers is that by copying
from xterm, they are entitled to do this whether or not the program
actually matches xterm's terminal description. This is unchanged
since the mid-2000s (see Debian #368916 for example).
* Konsole does this as well—intentionally as shown in KDE #145977 –
Konsole has a terminfo entry of its own; please change default
$TERM. The reasoning expressed there is that Konsole "should" match
xterm. Incidentally, one of the comments (about xterm's support for
mouse) cited as proof a page about Gpm from Linux Journal which was
more than 12 years old.
Each of the programs noted here which are well-established and which
are known to differ markedly from xterm have their own terminal
descriptions in ncurses, to which TERM should be set. Otherwise,
bug-reports are misdirected to ncurses which should have been addressed
by the respective developers of these programs. These include
* Eterm
* gnome (obsolete)
* konsole
* mlterm
* mrxvt
* putty
* rxvt
* st
* vte (preferred)
Comparing versions, by counting controls
Several of these programs are claimed (either by their developers, or
their users) to emulate "most" of xterm. To me, "most" would be
something quantifiable, e.g., 80 percent. To satisfy my curiousity, I
wrote a script to extract the control sequence information from
ctlseqs.txt. This counts each control sequence, as well as the
variations such as setting bold, color, inverse video. Then I
(laboriously) inspected these terminal implementations:
* xterm patch #266 ("xterm-new")
* X11R6.3 xterm (xterm-r6)
* DEC vt220
* DEC vt102
* rxvt 2.7.10
* rxvt-unicode 9.09 (urxvt)
* konsole 2.5.3
* VTE 0.25.91 (vte), used in GNOME-Terminal and kindred.
As of mid-November 2010, these were the latest implementations. I
included data for the vt220 and vt102 to be able to contrast the
various terminal emulators against those as well as xterm. There were:
* 498 control sequences listed in the corresponding file for xterm
patch #266.
* 192 of those are "primary", e.g., disregarding parameters such as
those distinguishing bold from color.
* 37 of the primary control sequences have secondary sequences.
For each control, there are three possibilities:
1. "yes" — the terminal implements it, matching xterm. If xterm
implements it, and it is a feature of vt220 or vt102, then in turn
xterm's behavior must match vt220 or vt102.
2. "partial" — the terminal implements it, but its behavior does not
match the reference noted above.
3. "no" — the terminal does not implement the control.
The control sequences document lists a few controls which xterm does
not (completely) implement, e.g.,
* key-repeat
* enabling LEDs other than scroll-lock
Those are not implemented in xterm because all X applications share the
same keyboard (see manpage), and xset is the proper tool for changing
auto-repeat. The X10R4 xterm did implement key-repeat, but the feature
was removed in X11R1. None of the other terminal emulators implements
those either.
CAPTION: Comparing against the control sequences document
yes partial no program
488 4 6 xterm-new
154 6 338 xterm-r6
188 5 305 vt220
104 0 394 vt102
204 3 291 rxvt
219 3 276 urxvt
191 2 305 putty
170 3 325 konsole
184 6 308 vte
Modern xterm implements 188 primary controls. In this table, vte ranks
lower than PuTTY because it does not support vt52 emulation. This is
not unusual, since the rxvt-based emulators do not, either. However,
all vt100's provide this feature; programs lacking this are not really
a vt100 emulator. On the other hand, PuTTY (which is not a vt100
emulator due to its incompatible wrapping behavior) supports this
feature.
Aside from that, the various emulators implement much the same features
from xterm. None implements as many as half of xterm's controls.
CAPTION: Comparing against xterm
yes partial no program
488 0 0 xterm-new
154 6 328 xterm-r6
182 2 304 vt220
98 0 390 vt102
204 3 281 rxvt
219 3 266 urxvt
189 2 297 putty
170 3 315 konsole
184 6 298 vte
DEC VT220 implements 96 primary controls. Modern xterm (as documented),
implements most of the VT220. VTE implements fewer than half. The
others are a little better. None of the others could be used as a real
VT220.
CAPTION: Comparing against vt220
yes partial no program
182 0 6 xterm-new
78 6 104 xterm-r6
188 0 0 vt220
104 0 84 vt102
101 3 84 rxvt
106 3 79 urxvt
107 2 79 putty
100 3 85 konsole
88 6 94 vte
DEC VT102 (the actual flavor used for "vt100" in most cases),
implements 68 primary controls. Again, VTE fares worst, and the others
a little better.
CAPTION: Comparing against vt102
yes partial no program
98 0 6 xterm-new
70 6 28 xterm-r6
104 0 0 vt220
104 0 0 vt102
79 2 23 rxvt
81 2 21 urxvt
86 2 16 putty
85 3 16 konsole
60 1 43 vte
I have continued to add features to xterm:
* as of September 2013, it implemented 546 of 556 documented controls
* as of October 2019, xterm implemented 713 of 723 documented
controls.
The other programs change far more slowly. As a result they implement a
smaller fraction of xterm's repertoire in 2019 than in 2010. Even for
cases where they implement a function, it may not work properly (see
for example the screenshot of VTE in the vttest NRCS examples).
In summary, none of the other terminal emulators emulates "most" of
xterm. Instead, they implement the most commonly-used control
sequences, and there are differences between them.
How do I ...
Not really problems, but frequently asked questions (the point of this,
after all):
* How do I change the font size?
* How do I print the screen?
* How do I set up function keys?
* How do I set the title?
* How do I make the cursor blink?
How do I change the font size?
XTerm uses fonts given as resource settings. You can switch between
these fonts at runtime, using a menu. This is documented in the
manpage, in the MENUS section.
X Consortium xterm provides popup menus, by pressing the control key
together with the mouse button. Control right mouse button pops up the
VT FONTS menu, from which you can select fonts that are specified in
xterm's resources. Usually these are in increasing order of size.
Modern xterm provides the menu, plus a feature adapted from rxvt:
pressing the shifted keypad plus or minus keys steps through the font
menu selections, in order of their size.
XTerm's manpage does not document the syntax for X resources; it is
done in the X documentation. If you are instead asking about a problem
displaying a given font, it may be due to a problem with your resource
settings.
How do I print the screen?
That depends on why you want to print it.
If you want a trace of an interactive session, you should use the
script program. It records every character sent to the screen,
recording them in a file typescript. There are two drawbacks to this
approach:
* Every character is recorded. Even cursor movement, if you run an
editor.
* You must start a new shell to capture the typescript file.
Well, what about logging? Some versions of xterm support logging to a
file. In fact modern xterm does. Logging was dropped from X Consortium
xterm during X11R5 due to security concerns. Those were addressed, but
logging was not reinstated (in fact there is a related bug in xterm).
Some people prefer this, because it is convenient: you can start and
stop logging a popup menu entry. However
* Every character is recorded. Even cursor movement, if you run an
editor.
* Line drawing characters are translated to control characters, i.e.,
codes 0-31 (this may be fixed sometime, it is a problem inherited
from X Consortium xterm).
Both script and logging are useful for recording, but they require
interpretation to make sense of the trace. You probably would not send
that trace to a printer (not twice, anyway).
If you want to print the contents of the screen, modern xterm
implements, as part of the VT100 emulation, an "attached" printer.
* The printer is really a pipe command, to which xterm writes.
* You can print the current line, page, or continuously with the
corresponding control sequences. That takes an application program
which knows how to print the screen.
* If you do not have an application, xterm has a popup menu entry to
print the window.
There are limitations and tradeoffs using the "attached" printer,
because it is an emulation:
* The emulation is based on detailed documentation for a VT320. This
states that control sequences are sent in each line to reset bold,
underlining and other printable attributes, and to set them as
needed. Your printer probably does not understand this sort of
input. Use the xterm resource printAttributes to get more easily
printed output.
* The printer may hang. Not really, but it seems that way. If you use
the "attached" printer from an application designed for the VT100
terminal, it is written with the assumption that the printer is a
dedicated piece of hardware, printing onto a continuous form. Use
the printerAutoClose resource to change xterm's behavior to close
the printer pipe whenever the terminal is told to switch the
printer offline.
If you use the popup menu to print the screen, this will close the
printer pipe unless it was already opened by the application running in
xterm.
How do I set up function keys?
With modern xterm, this is relatively simple. So I'll answer that
first.
With X Consortium xterm, you had partial support for DEC VTxxx function
keys. Function keys F1 to F12 correspond to DEC's F1 to F12 (sort of).
Actually, DEC's VT220 terminals do not have codes for F1 through F5.
They are reserved for local functions. And the VT220 (and up) terminals
have 20 function keys. So you cannot do anything with the F13 through
F20 (i.e., DO, HELP and SELECT). Finally, though xterm is reputed to be
VT100-compatible, it has no support for the VT100 keypad (PF1 to PF4,
and the "," key).
Modern (XFree86) xterm changed the X Consortium codes for F1 to F4 to
match the VT100 PF1 to PF4, except when the emulation level is VT220
and up. In this case, it generates the same F1 to F4 codes as X
Consortium xterm. Moreover, it adds a new resource sunKeyboard, which
tells the program whether it has only 12 function keys (i.e., a Sun or
PC keyboard). If so (this is selectable from the popup menu), you can
use the control key with F1 to F12 to get F13 to F24, and use the "+"
key on the keypad as an alias for "," (comma).
The emulation level for modern xterm is set via the resource
decTerminalID, e.g., to 220 for a VT220. Once set, applications can set
the emulation level up or down within that limit. DEC's terminals are
configured in much the same way by a setup option.
That is the simple way, using a couple of new resources. The
traditional way to get function keys involves translations. I have seen
a few postings on the newsgroups that do this. Here is one from Bruce
Momjian <root@candle.pha.pa.us> for a VT220:
xterm $XTERMFLAGS +rw +sb +ls $@ -tm 'erase ^? intr ^c' \
-name vt220 -title vt220 -tn xterm-220 "$@" &
with the corresponding resources:
XTerm*VT100.translations: #override \n\
<Key>Home: string(0x1b) string("[3~") \n \
<Key>End: string(0x1b) string("[4~") \n
vt220*VT100.translations: #override \n\
~Shift <Key>F1: string(0x1b) string("OP") \n \
~Shift <Key>F2: string(0x1b) string("OQ") \n \
~Shift <Key>F3: string(0x1b) string("OR") \n \
~Shift <Key>F4: string(0x1b) string("OS") \n \
~Shift <Key>F5: string(0x1b) string("[16~") \n \
~Shift <Key>F6: string(0x1b) string("[17~") \n \
~Shift <Key>F7: string(0x1b) string("[18~") \n \
~Shift <Key>F8: string(0x1b) string("[19~") \n \
~Shift <Key>F9: string(0x1b) string("[20~") \n \
~Shift <Key>F10: string(0x1b) string("[21~") \n \
~Shift <Key>F11: string(0x1b) string("[28~") \n \
~Shift <Key>F12: string(0x1b) string("[29~") \n \
Shift <Key>F1: string(0x1b) string("[23~") \n \
Shift <Key>F2: string(0x1b) string("[24~") \n \
Shift <Key>F3: string(0x1b) string("[25~") \n \
Shift <Key>F4: string(0x1b) string("[26~") \n \
Shift <Key>F5: string(0x1b) string("[K~") \n \
Shift <Key>F6: string(0x1b) string("[31~") \n \
Shift <Key>F7: string(0x1b) string("[31~") \n \
Shift <Key>F8: string(0x1b) string("[32~") \n \
Shift <Key>F9: string(0x1b) string("[33~") \n \
Shift <Key>F10: string(0x1b) string("[34~") \n \
Shift <Key>F11: string(0x1b) string("[28~") \n \
Shift <Key>F12: string(0x1b) string("[29~") \n \
<Key>Print: string(0x1b) string("[32~") \n\
<Key>Cancel: string(0x1b) string("[33~") \n\
<Key>Pause: string(0x1b) string("[34~") \n\
<Key>Insert: string(0x1b) string("[2~") \n\
<Key>Delete: string(0x1b) string("[3~") \n\
<Key>Home: string(0x1b) string("[1~") \n\
<Key>End: string(0x1b) string("[4~") \n\
<Key>Prior: string(0x1b) string("[5~") \n\
<Key>Next: string(0x1b) string("[6~") \n\
<Key>BackSpace: string(0x7f) \n\
<Key>Num_Lock: string(0x1b) string("OP") \n\
<Key>KP_Divide: string(0x1b) string("Ol") \n\
<Key>KP_Multiply: string(0x1b) string("Om") \n\
<Key>KP_Subtract: string(0x1b) string("OS") \n\
<Key>KP_Add: string(0x1b) string("OM") \n\
<Key>KP_Enter: string(0x1b) string("OM") \n\
<Key>KP_Decimal: string(0x1b) string("On") \n\
<Key>KP_0: string(0x1b) string("Op") \n\
<Key>KP_1: string(0x1b) string("Oq") \n\
<Key>KP_2: string(0x1b) string("Or") \n\
<Key>KP_3: string(0x1b) string("Os") \n\
<Key>KP_4: string(0x1b) string("Ot") \n\
<Key>KP_5: string(0x1b) string("Ou") \n\
<Key>KP_6: string(0x1b) string("Ov") \n\
<Key>KP_7: string(0x1b) string("Ow") \n\
<Key>KP_8: string(0x1b) string("Ox") \n\
<Key>KP_9: string(0x1b) string("Oy") \n
! <Key>Up: string(0x1b) string("[A") \n\
! <Key>Down: string(0x1b) string("[B") \n\
! <Key>Right: string(0x1b) string("[C") \n\
! <Key>Left: string(0x1b) string("[D") \n\
*visualBell: true
*saveLines: 1000
*cursesemul: true
*scrollKey: true
*scrollBar: true
Note that real VT220 terminals use shifted function keys to mean
something different: the user-programmable keys (i.e., DECUDK). Modern
xterm supports this, but the translations do not (they're using shift
to select F13 to F20).
Here's another one, from Robert Ess <ress@spd.dsccc.com>:
#!/bin/sh
# vax
# 09-17-96 Bob Ess - initial creation
# 09-26-96 Shig Katada - Additional keybindings
#
# Script file to incorporate keybindings and command l
ine
# options for connecting to a VAX node
# Usage statement
Usage(){
echo
echo " Usage : vax -options"
echo
echo " Options: -80 for 80 column terminal"
echo " -132 for 132 column terminal"
echo " -fg colorname"
echo " -bg colorname"
echo " -fn fontname"
echo " -fb bold fontname"
echo " -host [altair] [devel] [leonis] [castor]"
echo ""
echo " Example: \"vax -80 -fg white -bg black -fn 9x15 -fb 9
x15b -host castor\""
echo " Starts a VAX session with an 80 column termi
nal"
echo " with a black background, white foreground, a
normal"
echo " font of 9x15 and a bold font of 9x15b, and c
onnects"
echo " to the node 'castor'"
echo
echo " If you need additional help, please call Wor
kstation"
echo " Services at x92396."
echo
exit 1
}
# Default to a black foreground with a white background.
# Use the 9x15 and 9x15bold fonts. Connect to castor by default.
#
FG=black
BG=white
HOST=castor
FONT=9x15
BFONT=9x15bold
COLS=80
# Parse the command line arguments
#
while [ $# != 0 ];
do
case $1 in
-80) COLS=80
FONT=spc12x24c
BFONT=spc12x24b
shift
;;
-132) COLS=132
FONT=9x15
BFONT=9x15b
shift
;;
-fg) shift
FG=$1
shift;;
-bg) shift
BG=$1
shift;;
-fn) shift
FONT=$1
shift;;
-fb) shift
BFONT=$1
shift;;
-host) shift
HOST=$1
shift;;
-help) Usage;;
*) Usage;;
esac
done
xterm -title "VAX" -sb -sl 1200 -geo ${COLS}x24 -fg ${FG} -bg ${BG}
\
-cr red -fn ${FONT} -fb ${BFONT} -xrm \
'XTerm*VT100.translations: #override \n\
<Key>Insert: string(\001) \n\
Shift <Key>Up: scroll-back(1,lines) \n\
Shift <Key>Down: scroll-forw(1,lines) \n\
Shift <Key>Right: string(0x1b) string("f") \n\
Shift <Key>Left: string(0x1b) string("b") \n\
Shift <Key>Delete: string(0x1b) string(0x08) \n\
Shift <Key>Tab: string(0x1b) string("*") \n\
<Key>0x1000FF0D: scroll-back(1,page) \n\
<Key>0x1000FF0E: scroll-forw(1,page) \n\
<Key>0x1000FF09: string(\010) \n\
<Key>0x1000FF0A: string(\005) \n\
<Key>BackSpace: string(0xff) \n\
<Key>Select: select-start() \n\
<Key>0x1000FF02: select-end(PRIMARY,CUT_BUFFER0) \n\
Meta <Key>0x1000FF02: select-end(CLIPBOARD) \n\
<Key>0x1000FF04: insert-selection(PRIMARY,CUT_BUFFER0
) \n\
Meta <Key>0x1000FF04: insert-selection(CLIPBOARD) \n\
<Key>F1: string(0x1b) string("OP") \n\
<Key>F2: string(0x1b) string("OQ") \n\
<Key>F3: string(0x1b) string("OR") \n\
<Key>F4: string(0x1b) string("OS") \n\
<Key>F5: string(0x1b) string("OA") \n\
<Key>F11: string(0x1b) string("[23~") \n\
<Key>F12: string(0x1b) string("[24~") \n\
<Key>KP_0: string(0x1b) string("Op") \n\
<Key>KP_1: string(0x1b) string("Oq") \n\
<Key>KP_2: string(0x1b) string("Or") \n\
<Key>KP_3: string(0x1b) string("Os") \n\
<Key>KP_4: string(0x1b) string("Ot") \n\
<Key>KP_5: string(0x1b) string("Ou") \n\
<Key>KP_Divide: string(0x1b) string("OP") \n\
<Key>KP_Multiply: string(0x1b) string("[29~") \n\
<Key>KP_Enter: string(0x1b) string("OM") \n\
<Key>KP_Subtract: string(0x1b) string("Om") \n\
<Key>KP_Add: string(0x1b) string("Ol") \n\
<Key>KP_Decimal: string(0x1b) string("On") \n\
<Btn1Down>: select-start() \n\
<Btn1Motion>: select-extend() \n\
<Btn1Up>: select-end(PRIMARY,CUT_BUFFER0) \n\
Button1<Btn2Down>: select-end(CLIPBOARD) \n\
Button1<Btn2Up>: ignore()' \
-e telnet $HOST &
Finally (for the moment) is a further modification of Robert Ess's
script by Erik Ahlefeldt, <oahlefel@metz.une.edu.au>. From his readme
file, for vmsterm:
This script is for people who wish to connect from a Linux or Unix
computer to a VMS computer using telnet and get a good VT100 or
VT220 emulation. The key mappings have been specifically designed to
emulate the VT terminal auxiliary numeric keypad, so that you can
use VMS EDT and TPU editors, as well as the many VMS applications
use keys PF1 to PF4. The script should work with any recent version
of Xterm using a standard extended IBM PC keyboard or a Sun
keyboard.
About the keymappings. First the auxiliary numeric keypad. My prime
objective with these mappings was to produce a setup that I could
use with the EDT and TPU editors which make extensive use of the
numeric keypad. The top row of keys PC numeric keypad (Num Lock,
Divide, Multiply, Subtract) are where you find PF1, PF2, PF3, PF4 on
a VT keyboard, so I have mapped them to PF1 thru PF4. The PC numeric
keypad Add key (+) takes up the space of two keys which are Minus
and Comma on the VT keyboard – I have mapped it to Comma (Delete
Character in the EDT editor). I have then used the PC Pause key to
map to VT key Minus (Delete Word in the EDT editor). The remaining
keys on the auxiliary numeric keypad are the same for PC and VT.
The six keys between the main and numeric keypads on the PC (Insert,
Home, Page Up, Delete End, Page Down) are usually mapped to the VT
keys by either position or by (approximate) function. As I rarely
use these keys I have mapped them by function as follows: PC key
Insert to VT Insert Here, PC Home to VT Find, PC Page Up to VT Prev,
PC Delete to VT Remove, PC End to VT Select, PC Page Down to VT
Next.
Function keys.
There are 12 function keys on the PC keyboard and 20 on the VT
keyboard, so I map PC F1 thru F12 to VT F1 thru F12 (except for
F1 thru F5 as noted below) and PC Shift F1 thru Shift F10 to VT
F11 thru F20.
The VT keys F1 thru F5 are local hardware function keys so there
is nothing to emulate, however some PC to VT emulations in the
past have mapped PF1 thru PF4 here, so I have done that too,
even though they are already mapped on the auxiliary numeric
keypad.
Xterm functionality.
You lose some xterm functions when you remap the keyboard,
however this script implements a scroll back buffer of 1000
lines which you scroll through using Shift and Up (a.k.a. Up
Arrow or Cursor Up key) or Shift and Down.
a summary of the keyboard mapping:
PC Key maps to VT Key.
------ ------
F1 PF1
F2 PF2
F3 PF3
F4 PF4
F5 unused
F6 F6
F7 F7
F8 F8
F9 F9
F10 F10
F11 F11
F12 F12
Shift F1 F11
Shift F2 F12
Shift F3 F13
Shift F4 F14
Shift F5 F15 (Help)
Shift F6 F16 (Do)
Shift F7 F17
Shift F8 F18
Shift F9 F19
Shift F10 F20
Shift F11 F11
Shift F12 F12
Print Help (F15)
Cancel Do (F16)
Pause Keypad Minus
Insert Insert Here
Delete Remove
Home Find
End Select
Prior Prev
Next Next
BackSpace BackSpace (sends DEL - ascii 127)
Num_Lock PF1
KP_Divide PF2
KP_Multiply PF3
KP_Subtract PF4
KP_Add Keypad Comma
KP_Enter Enter
KP_Decimal Period
KP_0 Keypad 0
KP_1 Keypad 1
KP_2 Keypad 2
KP_3 Keypad 3
KP_4 Keypad 4
KP_5 Keypad 5
KP_6 Keypad 6
KP_7 Keypad 7
KP_8 Keypad 8
KP_9 Keypad 9
Up Up
Shift Up Scroll Back
Down Down
Shift Down Scroll Forward
Right Right
Left Left
and the script:
#!/bin/sh
# vmsterm
# from an original script by Bob Ess
# key translations by Erik Ahlefeldt
#
# Script file using Xterm and telnet to connect to a V
MS host
# and give a decent vt220 emulation.
#
# Usage statement
Usage(){
echo
echo " Usage : vmsterm -options"
echo
echo " Options: -80 for 80 column terminal"
echo " -132 for 132 column terminal"
echo " -bg colorname"
echo " -fg colorname"
echo " -fn fontname"
echo " -fb bold fontname"
echo " -host [crusher.saltmine.com] [earth] [192.16
8.7.7]"
echo ""
echo " Example: \"vmsterm -80 -fg white -bg black -fn 9x15 -
fb 9x15b -host earth\""
echo " Starts a VMS session with an 80 column termi
nal"
echo " with a black background, white foreground, a
normal"
echo " font of 9x15 and a bold font of 9x15b, and c
onnects"
echo " to the node 'earth'"
echo ""
echo " Example: \"vmsterm -host earth\""
echo " Starts a VMS session with default terminal s
ettings "
echo ""
echo " Example: \"vmsterm -help\""
echo " Displays vmsterm options "
echo
exit 1
}
# Default to a black foreground with a white background.
# Use the 9x15 and 9x15bold fonts. Connect to 192.168.3.3 by default
.
#
FG=black
BG=white
HOST=192.168.3.3
FONT=9x15
BFONT=9x15bold
COLS=80
# Parse the command line arguments
#
while [ $# != 0 ];
do
case $1 in
-80) COLS=80
FONT=spc12x24c
BFONT=spc12x24b
shift
;;
-132) COLS=132
FONT=9x15
BFONT=9x15b
shift
;;
-fg) shift
FG=$1
shift;;
-bg) shift
BG=$1
shift;;
-fn) shift
FONT=$1
shift;;
-fb) shift
BFONT=$1
shift;;
-host) shift
HOST=$1
shift;;
-help) Usage;;
*) Usage;;
esac
done
xterm -title "VMSTERM" -sb -sl 1000 -geo ${COLS}x24 -fg ${FG} -bg
${BG} \
-cr blue -fn ${FONT} -fb ${BFONT} -xrm \
"XTerm*vt100.translations: #override \n \
~Shift <Key>F1: string(0x1b) string("OP") \n \
~Shift <Key>F2: string(0x1b) string("OQ") \n \
~Shift <Key>F3: string(0x1b) string("OR") \n \
~Shift <Key>F4: string(0x1b) string("OS") \n \
~Shift <Key>F5: string("Break") \n \
~Shift <Key>F6: string(0x1b) string("[17~") \n \
~Shift <Key>F7: string(0x1b) string("[18~") \n \
~Shift <Key>F8: string(0x1b) string("[19~") \n \
~Shift <Key>F9: string(0x1b) string("[20~") \n \
~Shift <Key>F10: string(0x1b) string("[21~") \n \
~Shift <Key>F11: string(0x1b) string("[23~") \n \
~Shift <Key>F12: string(0x1b) string("[24~") \n \
Shift <Key>F1: string(0x1b) string("[23~") \n \
Shift <Key>F2: string(0x1b) string("[24~") \n \
Shift <Key>F3: string(0x1b) string("[25~") \n \
Shift <Key>F4: string(0x1b) string("[26~") \n \
Shift <Key>F5: string(0x1b) string("[28~") \n \
Shift <Key>F6: string(0x1b) string("[29~") \n \
Shift <Key>F7: string(0x1b) string("[31~") \n \
Shift <Key>F8: string(0x1b) string("[32~") \n \
Shift <Key>F9: string(0x1b) string("[33~") \n \
Shift <Key>F10: string(0x1b) string("[34~") \n \
Shift <Key>F11: string(0x1b) string("[28~") \n \
Shift <Key>F12: string(0x1b) string("[29~") \n \
<Key>Print: string(0x1b) string("[28~") \n \
<Key>Cancel: string(0x1b) string("[29~") \n \
<Key>Pause: string(0x1b) string("Om") \n \
<Key>Insert: string(0x1b) string("[2~") \n \
<Key>Delete: string(0x1b) string("[3~") \n \
<Key>Home: string(0x1b) string("[1~") \n \
<Key>End: string(0x1b) string("[4~") \n \
<Key>Prior: string(0x1b) string("[5~") \n \
<Key>Next: string(0x1b) string("[6~") \n \
<Key>BackSpace: string(0x7f) \n \
<Key>Num_Lock: string(0x1b) string("OP") \n \
<Key>KP_Divide: string(0x1b) string("OQ") \n \
<Key>KP_Multiply: string(0x1b) string("OR") \n \
<Key>KP_Subtract: string(0x1b) string("OS") \n \
<Key>KP_Add: string(0x1b) string("Ol") \n \
<Key>KP_Enter: string(0x1b) string("OM") \n \
<Key>KP_Decimal: string(0x1b) string("On") \n \
<Key>KP_0: string(0x1b) string("Op") \n \
<Key>KP_1: string(0x1b) string("Oq") \n \
<Key>KP_2: string(0x1b) string("Or") \n \
<Key>KP_3: string(0x1b) string("Os") \n \
<Key>KP_4: string(0x1b) string("Ot") \n \
<Key>KP_5: string(0x1b) string("Ou") \n \
<Key>KP_6: string(0x1b) string("Ov") \n \
<Key>KP_7: string(0x1b) string("Ow") \n \
<Key>KP_8: string(0x1b) string("Ox") \n \
<Key>KP_9: string(0x1b) string("Oy") \n \
~Shift <Key>Up: string(0x1b) string("[A") \n \
Shift <Key>Up: scroll-back(1,lines) \n \
~Shift <Key>Down: string(0x1b) string("[B") \n \
Shift <Key>Down: scroll-forw(1,lines) \n \
<Key>Right: string(0x1b) string("[C") \n \
<Key>Left: string(0x1b) string("[D")" \
-e telnet $HOST
How do I set the title?
The control sequences for doing this are documented in ctlseqs.ms.
The usual context for this question is setting the title according to
the current working directory. People post answers to this periodically
on the newsgroups. Here is one that I have seen, from Roy Wright
<nobody@roystoy.dseg.ti.com>. In your /etc/profile after:
if [ "$SHELL" = "/bin/pdksh" -o "$SHELL" = "/bin/ksh" ]; then
PS1="! $ "
elif [ "$SHELL" = "/bin/zsh" ]; then
PS1="%m:%~%# "
elif [ "$SHELL" = "/bin/ash" ]; then
PS1="$ "
else
PS1='\u@\h:\w\$ '
fi
add:
if [ "$TERM" = "xterm" ]; then
PS1="\033]2;\u@\h:\w\007bash$ "
fi
The terminator "\007" is a problem area. XTerm historically uses this
character, though it is non-ANSI. The "correct" character should be a
"\233" string terminator, or "\033\\", which is the 7-bit equivalent.
Modern xterm recognizes either (the "\007" or string terminator);
waiting for the first of these.
You may have resource or environment problems that prevent you from
setting the title at all. Newer xterms (starting somewhere in X11R5)
use the $LANG variable. If your locale is incorrectly installed, you
will be unable to set the xterm's title. As noted by Mikhail Teterin
<mi@rtfm.ziplink.net>: Make sure that the locale (LANG and/or LOCALE
environment variable) is known to X Window System. Check
${X11ROOT}/lib/X11/locale.* for it. If it is not listed in either one
of the files, find the nearest match and add an alias to it. Restart X
if you have made changes.
On a related note, some people want to know how to read the title from
an xterm. This works for modern xterm and dtterm, but not for other
variations:
#!/bin/ksh
# Echo the current X term title bar to standard output.
# Written by Icarus Sparry <icarus@bath.ac.uk> 11 Apr 1997
#
exec </dev/tty
old=$(stty -g)
stty raw -echo min 0 time ${1-10}
print "\033[21t\c" > /dev/tty
IFS='' read -r a
stty $old
b=${a#???}
print -R "${b%??}"
But it is possible to avoid escape sequences altogether (from Hemant
Shah <shah@typhoon.xnet.com>):
$ xprop -id $WINDOWID | grep WM_NAME
WM_NAME(STRING) = "this is my title"
current_title=$(xprop -id $WINDOWID | grep WM_NAME | cut -d= -f2)
Here's another source of information: Xterm-Title HowTo
How do I make the cursor blink?
Standard xterm does not implement a blinking cursor. Some of the
variations do: dtterm, GNOME Terminal, and modern xterm (from mid 1999,
patch 107).
Frequent problems
* Starting xterm, or not
+ Xterm does not run (no available pty's)
+ I need /etc/termcap
+ Why does $LD_LIBRARY_PATH get reset?
+ Why do the -e and -ls options not work together?
+ Why is my screen size not set?
+ Why are the menus tiny?
* Font problems
+ My terminal doesn't show box characters
+ The bold font is ugly
+ I see little dots on the screen
+ My terminal doesn't display Cyrillic characters
+ I see boxes instead of characters in uxterm
+ I see question-marks instead of characters in uxterm
+ The first popup menu is very slow
* Keyboard problems
+ Why can't I input 8-bit characters?
+ Why doesn't my delete key work?
+ Why did my delete key stop working?
+ Well, how can I set my delete key?
+ Why doesn't my keypad work?
+ How can my program distinguish control-I from tab?
+ Why can't I use the pageup/pagedown keys?
+ Why can't I use the home/end keys?
+ Why can't I use the cursor keys in (whatever) shell?
+ Alt-keys do not work in bash
* Colors and other graphic rendition
+ My terminal doesn't recognize color
+ What $TERM should I use?
+ Reverse video is not reset
+ My colors changed in vim
+ Aren't bright colors the same as bold?
+ Can I set a color by its number?
+ I don't like that shade of blue
+ Why doesn't xterm support italics?
+ "grep --color" does not show the right output
+ That description of wrapping is odd, say more?
+ That color scheme is odd, say more?
* Odd behavior
+ Why can't I select/paste in xterm?
+ Why can't I select/paste to/from other programs?
+ Why can't I select tab-characters in xterm?
+ Can bracketed-paste solve my problems?
+ FVWM does weird things when I try to resize xterm
+ Why doesn't the screen clear when running vi?
+ Why doesn't the screen clear when I type control/L?
+ Why is the cursor misplaced after running vi?
+ Why doesn't the scrollbar work?
+ Can I improve the scrollbars?
+ Can I improve the scrolling speed?
+ Why can't my program read the window title?
+ Why can't my program set the window size?
+ Why is the text in the wrong place?
* Sample .Xdefaults Color-Settings for XTerm
* What is this warning message?
Starting xterm, or not
XTerm does not run (no available pty's)
Your copy of xterm may not have enough permissions to use existing
pty's:
* you may have to make xterm run setuid to root (though newer systems
have wrappers that make this unnecessary).
* the pty's permissions may be restrictive (that is ok, but you have
to make xterm agree with it). Usually this is done by making the
group ownership of the pty's "tty", and requiring that xterm run
setgid to "tty". This is done rather than make xterm run setuid to
root, since that presents problems with security.
* newer systems (with Unix98 pty's) have a single entry under /dev
which has to have the right permissions. For example:
# ls -l /dev/ptmx
crw-rw---- 1 root tty 5, 2 Aug 21 20:19 /dev/ptmx
Perhaps your system does not have enough pty's, or (problems reported
with newer Linux kernels supporting Unix98 pty's, beginning with RedHat
6.0) the major device numbers of the pty's may have changed during a
kernel upgrade. (This is described in /usr/src/linux/Documentation).
See also the MAKEDEV script, which usually exists under /dev.
I need /etc/termcap
If you have a termcap version of xterm on a system with no termcap
libraries, you may also be missing /etc/termcap.
A workaround is to copy /usr/X11R6/lib/X11/etc/xterm.termcap to
/etc/termcap.
This is fixed another way starting with XFree86 3.3.1. If xterm cannot
find the terminal description, it will accept that, though it will
print a warning. If xterm does not find the termcap entry, it will not
set the $TERMCAP variable.
Why does $LD_LIBRARY_PATH get reset?
If xterm is running setuid (which is needed on some systems which have
no wrappers for opening pty's and updating utmp), newer systems
automatically set or reset environment variables which are considered
security problems. These include $PATH and $LD_LIBRARY_PATH, since they
affect the choice of which programs are run if not specified via a full
pathname.
This means, for example, that if you attempt to run
xterm -e foo
where foo is a program that uses shared libraries in /usr/local/lib,
then the command will fail, because /usr/local/lib is not considered
part of root's environment.
Modern Unix systems (such as recent Solaris and HPUX versions) do not
require you to run xterm setuid. Some will result in odd malfunctions
if you do this.
Why do the -e and -ls options not work together?
XTerm has two useful options for controlling the shell that is run:
-e
tells xterm to execute a command using the remaining parameters
after this option.
-ls
tells xterm to invoke a login shell, making it read your .login
file, for instance.
The two are not compatible. If you specify both, xterm uses -e, and if
that fails for whatever reason will fall through to the -ls option. It
cannot (in general) combine the two, since some shells permit this
(e.g., bash), and others do not (e.g., tcsh).
Why is my screen size not set?
Well, it may be set, but not correctly. You may notice these symptoms:
* When editing with vi, you cannot see the beginning of the file, or
* Running
stty -a
shows the rows and/or columns values as 0, or some other value
(such as 65) which has nothing to do with the actual window size.
XTerm knows how big the screen is (of course), and tries to tell your
applications (e.g., by invoking ioctl's and sending SIGWINCH). But
sometimes it cannot:
* XTerm itself may have been built incorrectly (the #ifdef's that
make the logic work are inactive).
* You may be running xterm via a remote connection which refuses to
pass that information. This can happen even on "modern" networks
where the connection crosses domain boundaries.
* You may be running su'd to another account. SIGWINCH is just
another signal; signals do not propagate for security reasons.
Most full-screen applications such as vi are designed to use the ioctl
calls that return the screen size. When they fail, the applications use
the size defined in the terminal's terminfo or termcap description.
You may be able to use the resize program to issue the ioctl's that
will notify your application of the actual screen size. This does not
always work for the reasons just mentioned. Newer versions of stty let
you specify the screen size, though it will not be updated if you
resize the xterm window:
stty rows 24 columns 80
Most full-screen applications also check if the $LINES and $COLUMNS
variables are set, using those values to override the terminal
description:
setenv LINES 24
setenv COLUMNS 80
Why 65 lines? The standard xterm terminfo description specifies 65
lines, perhaps because someone liked it that way. Real VT100's are 24
lines. I once used (and wrote applications for) a Bitgraph terminal,
which emulated VT100, but displayed 65 lines.
Why are the menus tiny?
Everything seems to work, except that the xterm menus (VT options,
fonts, etc.) do not display properly; the menus pop up, but only with a
tiny display area in which none of the options are visible (and only
part of the menu title is visible).
You have specified the geometry for xterm too high in the hierarchy,
and that 24x80 (or whatever the -geometry parameter happens to be) is
applying to the menus in pixels. This resource makes the geometry apply
to the menus as well as the VT100 widget:
XTerm*geometry: 80x24
while this applies only to the VT100 widget (which is probably what you
intended):
XTerm.VT100.geometry: 80x24
or better yet (to allow for the toolbar option, which uses a level of
widget hierarchy):
XTerm*VT100.geometry: 80x24
Font problems
My terminal doesn't show box characters
XTerm displays the 7-bit ASCII and VT100 graphic characters (including
box corners) using specially arranged fixed-pitch fonts. The first 32
glyph positions (which would correspond to nonprinting control
characters) are used to hold the VT100 graphic characters. Some fonts
that otherwise look fine (such as courier) do not have glyphs defined
for these positions. So they display as blanks. Use xfd to display the
font.
Modern xterm can form its own line-drawing characters (see patch 90,
for example). It does not draw all of the graphic characters, only
those that may be done with straight lines. But those are the most
used, making most of the fixed-pitch fonts useful for xterm.
You may also have a problem with the terminfo description. As
distributed, the X11R6 terminfo for xterm does not have the acsc string
defined, so most implementations of curses do not try to use the
alternate character set.
Finally, some people confuse the VT100 graphic characters with the
VT220 support for DEC technical character set. These are distinct
(7-bit) character sets. Xterm currently does not support this.
The bold font is ugly
XTerm lets you directly specify one bold font, which is assumed to
correspond to the default font. Older versions of xterm make a fake
bold font for the other choices via the fonts menu by drawing the
characters offset by one pixel. I modified xterm to ask the font server
for a bold font that corresponds to each font (other than the default
one). Usually that works well. However, sometimes the font server gives
a poor match. Xterm checks for differences in the alignment and size,
but the font server may give incorrect information about the font size.
The scaled bitmap font feature gives poor results for the smaller
fonts. In your X server configuration file, that can be fixed by
disabling the feature, e.g., by appending ":unscaled" to the path:
FontPath "/usr/lib/X11/fonts/100dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/75dpi/:unscaled"
FontPath "/usr/lib/X11/fonts/misc/:unscaled"
You can suppress xterm's overstriking for bold fonts using the
alwaysBoldMode and related resources. However, rendering ugly bold
fonts is a "feature" of the font server. In particular, the TrueType
interface provides less ability to the client for determining if a
particular font supports a bold form.
I see little dots on the screen
Well, I do. Perhaps you do not. It depends on the fonts you choose, and
how you use them.
Standard xterm has a "normal" font for which a bold font can be chosen,
and several alternative fonts, useful for changing the font size. The
alternative fonts do not have corresponding bold fonts. Xterm simulates
bold fonts in this case by overstriking the character one pixel offset.
That can make an bold character extend into the area that another
character occupies. When erasing a bold character from the screen,
xterm does not erase the extra pixel. This is corrected in modern
xterm, subject to the available fonts (from late 1998, patch 85). For
each font, it asks the font server for a corresponding bold font. Your
font server may not have the bold font (or it may incorrectly report
that it does). But it usually works.
My terminal doesn't display Cyrillic characters
Cyrillic encodings typically use characters in the range 128-159. For a
VT220 (or any terminal that follows ISO 6429), those are treated as
control characters. Still, some people want to use KOI8-R, etc. I
modified xterm in patch 175 to add an option (-k8) and corresponding
resource settings to allow them to customize their environment. Here is
a sample script and resource file which I use for testing this
configuration.
I see boxes instead of characters in uxterm
XTerm may show boxes instead of characters if the font that you have
selected does not contain those characters. Normally you can fix most
of that using the UTF-8 feature, with uxterm. However, your X resource
settings may be the source of the problem.
One pitfall to setting X resources is that they allow you to specify
wildcards, e.g., the "*" character. When you give a wildcard, the X
resource matches any number of levels in the widget hierarchy.
XTerm has more than one widget matching "font" at different levels of
the hierarchy. There are the popup menus, and there are the fonts used
for uxterm. The latter is where an overbroad pattern can cause xterm to
use a different font than you expect.
Suppose your resource setting includes this pattern
*VT100*font: fixed
It could be interpreted as this:
*VT100.font: fixed
*VT100.utf8Fonts.font: fixed
XTerm uses the utf8Fonts subresources to provide runtime-switchable
fonts between IS0-8859-1 (Latin-1) and ISO-10646 (Unicode). Modifying
the Unicode font to "fixed" will make most of the characters
unavailable (i.e., shown as boxes). If instead your resource looks like
*VT100.font: fixed
it would be unambiguous, and not modify the utf8Fonts value.
I see question-marks instead of characters in uxterm
You may be seeing a question mark in a black diamond, like this:
�
That is called the Unicode replacement character. It is used when a
program is told to display a character which is not in the Unicode
system. The program replaces the illegal/invalid character with this
symbol. That is different from boxes, which xterm displays when it has
nothing in the current font for a valid Unicode character.
Unicode's rules are oriented toward handling input in different
encodings, and displaying the corresponding Unicode value. Although
Unicode has rules and a definition for the valid characters, different
programs may handle invalid input in different ways. This page gives an
overview of how xterm may differ from other programs in that regard.
The first popup menu is very slow
Some users report that when starting xterm, it is very slow, that their
computer's CPU time increases, etc.
This is a longstanding bug in the X libraries. There is a workaround
using a resource setting for xterm.
Details
XTerm uses the Athena (Xaw) widgets to display popup menus. In the
normal case, those are initialized one-by-one as they are first used.
If you have configured xterm to use its toolbar configuration, they are
all initialized on startup. In the latter, performance problems are
more noticeable.
The Athena widgets XawInitializeWidgetSet function goes through several
levels down to the X library _XlcAddUtf8LocaleConverters function to
call create_tocs_conv and related functions to make a list of character
sets from the locale, which is used in menus to get all possible fonts
needed for a fontset.
If your current locale uses UTF-8 encoding, this will read a long list
of bitmap fonts—everything whose encoding might be useful for
displaying the menus. For example, this list (from lcUTF8.c) which
dates from around 2000 is the core of the problem:
ISO10646-1, ISO8859-1, ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5,
ISO8859-6, ISO8859-7, ISO8859-8, ISO8859-9, ISO8859-10, ISO8859-11,
ISO8859-13, ISO8859-14, ISO8859-15, ISO8859-16, JISX0201.1976-0,
TIS620-0, GB2312.1980-0, JISX0208.1983-0, JISX0208.1990-0,
JISX0212.1990-0, KSC5601.1987-0, KOI8-R, KOI8-U, KOI8-C, TATAR-CYR,
ARMSCII-8, IBM-CP1133, MULELAO-1, VISCII1.1-1, TCVN-5712,
GEORGIAN-ACADEMY, GEORGIAN-PS, ISO8859-9E, MICROSOFT-CP1251,
MICROSOFT-CP1255, MICROSOFT-CP1256, BIG5-0, BIG5-E0, BIG5-E1,
ISO10646-1, ISO10646-1
However, xterm is going to use only the characters shown in the popup
menus. It is unlikely that you need Chinese fonts for that.
Solution
XTerm's menuLocale resource can be set to an explicit value, e.g., "C"
to override the current locale as seen by this initialization debacle.
Limitations
The workaround does not prevent some hacker from "improving" the X
libraries still further.
Keyboard problems
Why can't I input 8-bit characters?
You must have the eightBitInput resource set to do this.
Why doesn't my delete key work?
This seems to have begun as a problem with the older XFree86 release
(3.1.2). I have picked up pieces of the story (xterm and the keyboard
work as designed under XFree86 3.2 and up).
The underlying problem is that we've accumulated three things that are
being equated as "Delete":
ASCII BS (backspace, code 8)
ASCII DEL (delete. code 127)
VT220 "remove" aka "delete" (ESC [ 3 ~)
You are probably talking about the backarrow key (on my keyboard, at
the upper right of the QWERTY block), or the key labeled delete which
is on the 6-key "editing keypad". Since xterm is emulating a
VT100/VT220, the backarrow key should generate a 127 (often displayed
as ^?). You would use a control/H to obtain a backspace on a real
VT220.
The reason why BS and DEL are of special interest is that on Unix, the
stty command and the underlying termios/termio system calls allow only
single-byte codes to be assigned to special functions such as erase.
For instance, you could see something like this on your terminal:
$ stty -a
speed 38400 baud; rows 40; columns 80; line = 0;
intr = ^C; quit = ^\; erase = ^H; kill = ^U; eof = ^D; eol = <undef>;
eol2 = <undef>; swtch = <undef>; start = <undef>; stop = <undef>; susp = <undef>
;
rprnt = ^R; werase = ^W; lnext = ^V; flush = ^O; min = 1; time = 0;
-parenb -parodd cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl ixon -ixoff
-iuclc -ixany -imaxbel -iutf8
-opost -olcuc -ocrnl -onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff
0
isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke
Tastes differ. On Unix, people expect the backarrow key to generate a
backspace (or not). As I understand it, at one point, XFree86 picked up
the sense of the erase character during initialization, so that xterm
would in effect use the same erase character as the console. The
current scheme (X11R6) uses keyboard mapping tables that are
independent of the environment.
Modern xterm (since patch #83 in 1998) provides a resource toggle
backarrowKey (and an escape sequence from VT320) that changes this key
between the two styles (backspace or delete).
With modern xterm patch 95 (also in the stable version as "88c"), you
may have an xterm which can automatically initialize the backarrow key
to backspace or delete depending on the pseudo terminal's sense, or
based on the termcap setting of kbs (backspace key). This feature is
controlled by the resource setting ptyInitialErase.
Why did my delete key stop working?
Well, something changed. You have to determine what did.
This may be because an upgrade introduced different X resource
settings, or because you are using the newer xterm with the
ptyInitialErase resource (or perhaps both). Use
appres XTerm
to see the X resources that you are using, in particular the
translation (or Translation) resource for the vt100 widget.
One unexpected scenario came out of hiding when I was implementing the
ptyInitialErase resource. When xterm is (by default) built to support
this, it sets the pty's erase character to match the termcap entry.
Xterm also sets the $TERMCAP environment variable to match. So
everything is consistent, and everything defined. The stty erase
character is either backspace (^H) or delete (^?).
The problem arises because there are two things called "delete", which
were not well-defined: ASCII delete (127) and the PC-style adaptation
of VT220 remove assigned to the key Delete.
However, the screen program prefers to make the termcap delete (kD) an
<escape>[3~, which corresponds to the VT220 remove key. If $TERMCAP is
set when starting screen, it will translate stty's erase character into
the <escape>[3~, making most curses and termcap applications work. But
stty still has the original erase character. So low-level applications
which check stty will not work. I found that unsetting $TERMCAP before
running would work, but this was not a good solution. Someone pointed
out (see patch 129), that the problem really was because termcap kD
should delete the character at the current position. So it cannot be
the same as stty erase.
As a matter of fact, stty erase has to be a single character, so
<escape>[3~ would not work anyway.
Well, how can I set my delete key?
When people first started asking this question in 1995-1996, it
appeared in the context of making Netscape work. Netscape's use of the
delete key running in X did not match user's expectations when compared
to that other platform. They were commonly advised to use xmodmap,
e.g.,
keysym BackSpace = Delete
or
keycode 22 = 0xff08
Either way is a bad technical solution – it works for some people but
not others (on my keyboard at work, keycode 22 is the numeric keypad
'9').
Alternatively, you can set resources. This works reasonably well for
environments where you have different versions of xterm, e.g.,
XTerm*VT100.translations: #override \n\
<Key>Delete: string(0x7f)
I do not do that either, because it is not flexible. Not all programs
use the same sense of stty erase; some use termcap or terminfo, and
some are hardcoded. So I prefer to be able to switch the xterm's
keyboard at runtime. You cannot do that with resources. (Or not really
– xterm has a keymap() action which could support this if you provided
a rather complex resource settings, but the X library support for that
is broken in X11R6). Instead, I have added to xterm a set of resources
(and popup menu entries) to allow simple switching between the
different styles of keyboard, in particular for the backspace/delete
issues. See the manual page for backarrowKey backarrowKeyIsErase and
deleteIsDEL as well as sunKeyboard.
Why doesn't my keypad work?
A few people have commented that the keypad does not work properly.
Aside from bugs (I have fixed a few), the most common problem seems to
be misconception.
Here's a picture of the VT100 numeric keypad:
+-----+-----+-----+-----+
| PF1 | PF2 | PF3 | PF4 |
+-----+-----+-----+-----+
| 7 | 8 | 9 | - |
+-----+-----+-----+-----+
| 4 | 5 | 6 | , |
+-----+-----+-----+-----+
| 1 | 2 | 3 | |
+-----+-----+-----+ ENT +
| 0 | . | |
+-----+-----+-----+-----+
and the similar Sun and PC keypads:
+-----+-----+-----+-----+
| NUM | / | * | - |
+-----+-----+-----+-----+
| 7 | 8 | 9 | |
+-----+-----+-----+ + +
| 4 | 5 | 6 | |
+-----+-----+-----+-----+
| 1 | 2 | 3 | |
+-----+-----+-----+ ENT +
| 0 | . | |
+-----+-----+-----+-----+
Working in X11, the NUM (NumLock) key has better uses than an alias for
PF1 (and is sometimes reserved). I use the F1 through F4 on the
keyboard to implement PF1 through PF4, alias the keypad "+" to "," and
use the existing "-" key.
VT220 emulation uses the VT100 numeric keypad as well as a 6-key
editing keypad. Here's a picture of the VT220 editing keypad:
+--------+--------+--------+
| Find | Insert | Remove |
+--------+--------+--------+
| Select | Prev | Next |
+--------+--------+--------+
and the similar Sun and PC keypads:
+--------+--------+--------+
| Insert | Home | PageUp |
+--------+--------+--------+
| Delete | End | PageDn |
+--------+--------+--------+
I chose to use keys that are mnemonic rather than in the "same"
positions, though some emulators (e.g., Tera Term) use the same
positions:
+--------+--------+--------+
| Insert | Find | Prev |
+--------+--------+--------+
| Remove | Select | Next |
+--------+--------+--------+
I test the keyboard (for VT52/VT100/VT220) using vttest. If you find
(or think that you have found) a problem with the keyboard handling of
xterm, please test it with vttest first.
Other arrangements of the keyboard are possible of course. If you
prefer to use the top row of the numeric keypad as PF1 through PF4, you
should do this using xterm's X resources.
In 2014, I noticed a comment, which relates to the PF1-PF4 assignment,
but also to the use of function-key modifiers.
Because that is a digression, I have expanded it in a separate page.
How can my program distinguish control-I from tab?
Your program can use xterm's modifyOtherKeys feature, e.g., using a
control sequence such as
\033 [ > 4 ; 2 m
to temporarily switch into a mode where shift, alt, control and meta
modifiers applied to a key tell xterm to send an escape sequence which
encodes all of that information. The tab key would send a tab, but
control-i would send
\033 [ 2 7 ; 5 ; 1 0 5 ~
while control-shift-i would send
\033 [ 2 7 ; 6 ; 7 3 ~
Your program should turn that off when it is not needed; it is a real
nuisance when you cannot type control-characters as they were meant to
be used:
\033 [ > 4 m
In 2019, Bram Moolenaar asked for more details about modifying other
keys; I have expanded that in a separate page.
Why can't I use the pageup/pagedown keys?
Some vendors, e.g,. Sun, added key translations which make the pageup
and pagedown keys talk to the xterm's scrollbar instead of your
application. They did the same thing for the home and end keys, thereby
obscuring a bug in xterm.
You can override this by specifying your own translations in your
resource file. The issue was first noted with Solaris 2.5, with the
file given in two locations:
/usr/lib/X11/app-defaults/XTerm
/usr/openwin/lib/app-defaults
using a symbolic link to relate the two. Later releases of Solaris,
e.g., 8-10 omitted the former location.
Solaris 11 provides modern xterm (patch #271), and does not have this
problem.
As of February 2014, I was able to verify that AIX and HPUX have
updated to modern xterm, e.g.,
* patch #180 on HPUX 11.31,
* patch #222 on AIX 6.1 and 7.1,
Older AIX and HPUX releases distributed the X Consortium (1994)
app-defaults file.
In updating this question in February 2014, I noticed that IBM added
their copyright notice in AIX's copy of the app-defaults file in
/usr/lpp/X11/lib/X11/app-defaults
There were no other changes to the file. Someone at IBM blundered.
In patch #252, I ensured that my copyright notice is on those files
(I am the sole author, and can do that).
Use the translations in the system's app-defaults file as a guide. The
relevant section of the app-default file looks like
*VT100.translations: #override \
@Num_Lock<Key>KP_0: string(0)\n\
@Num_Lock<Key>KP_1: string(1)\n\
@Num_Lock<Key>KP_2: string(2)\n\
@Num_Lock<Key>KP_3: string(3)\n\
@Num_Lock<Key>KP_4: string(4)\n\
@Num_Lock<Key>KP_5: string(5)\n\
@Num_Lock<Key>KP_6: string(6)\n\
@Num_Lock<Key>KP_7: string(7)\n\
@Num_Lock<Key>KP_8: string(8)\n\
@Num_Lock<Key>KP_9: string(9)\n\
@Num_Lock<Key>KP_Add: string(+)\n\
@Num_Lock<Key>KP_Decimal: string(.)\n\
@Num_Lock<Key>KP_Divide: string(/)\n\
@Num_Lock<Key>KP_Enter: string(\015)\n\
@Num_Lock<Key>KP_Equal: string(=)\n\
@Num_Lock<Key>KP_Multiply: string(*)\n\
@Num_Lock<Key>KP_Subtract: string(-)\n\
<Key>Prior:scroll-back(1,page)\n\
<Key>Next:scroll-forw(1,page)\n\
<Key>F16: start-extend() select-end(PRIMARY, CUT_BUFFER0, CL
IPBOARD) \n\
<Key>F18: insert-selection(PRIMARY, CLIPBOARD) \n\
<Key>F27: scroll-back(100,page) \n\
<Key>R13: scroll-forw(100,page) \n\
<Key>Home: scroll-back(100,page) \n\
<Key>End: scroll-forw(100,page) \n
For example, a more-specific pattern for the resource name lets you
override:
XTerm*VT100.translations: #override \n\
~Shift<Key>Home: string(\033[1~)\n\
~Shift<Key>End: string(\033[4~)\n\
~Shift<Key>Prior: string(\033[5~)\n\
~Shift<Key>Next: string(\033[6~)\n\
Shift<Key>Prior: scroll-back(1,page) \n\
Shift<Key>Next: scroll-forw(1,page) \n\
Shift<Key>Home: scroll-back(100,page) \n\
Shift<Key>End: scroll-forw(100,page) \n
makes the home/end and pageup/pagedown keys usable by your editor,
while leaving their shifted equivalents available for the scrollbar.
Why can't I use the home/end keys?
This is a long story, unless you are referring to X Consortium xterm.
That program is simply broken in this respect.
At the beginning, when the home/end keys were fixed for modern xterm
(in early 1996), there was some discussion regarding what the escape
sequences should be for those keys (for the 6-key editing keypad).
Those were chosen as "PC-style" codes (like SCO "ansi"), i.e.,
ESC [ H
ESC [ F
for normal mode, and
ESC O H
ESC O F
for cursor application mode.
That style of coding fit easily into the existing logic of xterm. It
was not my change, and (because xterm should be based upon standards),
I did question this, and asked the opinion of the person who was at
that time developing rxvt. He had chosen a layout based on DEC's VT220
terminals, though the key labels on the typical PC keyboard did not
match. At that point, neither of us knew enough to make a good case for
this.
Somewhat later I could see that xterm had a number of undocumented
extensions to support the VT220-style (pre-ISO 2022) character sets. I
decided to complete the functionality by making xterm a VT220 emulator.
This would require that it provide the same escape sequences for the
editing and numeric keypads. I could not simply change the escape
sequences from "PC-style" to "VT220-style", since a number of users
"knew" that the keypad "ought to" send home, end, cursor keys, etc.,
because they had labels indicating that use. To retain compatibility
(but allow easy reconfiguration to make a VT220 emulator), I added
popup-menu items to switch between the modes. With minor refinements,
this was the approach for about two years, culminating with the
"stable" patch #88, which is essentially the version distributed with
XFree86 3.3.x.
NOTE:
the terminfo distributed with xterm patch #88 is incorrect: the
escape sequences given for home/end keys are the VT220-style,
rather than the default PC-style. Too accustomed to switching
modes on the fly, I overlooked a line in my .Xdefaults file:
*sunKeyboard: true
Downstream packagers (when they noticed this) accommodated the
bug by modifying the VT100 translations resource which is not a
good technical solution since it interferes with the users'
ability to modify that resource. For example, Red Hat bug
#100695 quoted a suggested patch which shows that the package
had overridden the xterm behavior for shifted function keys. See
this for more discussion.
But xterm continues to evolve past the stable patch #88. The keyboard
support was still unsatisfactory for two reasons:
* some users wanted to be able to use applications that detected
whether the control key was pressed (e.g., control/F1).
* the compromises made for xkb with X11R6 interfered with xterm's use
of the NumLock key for the numeric keypad.
The former could be addressed by expanding the escape sequences sent by
the PC-style function keys, while the latter was a VT100/VT220 design
issue. I decided to redesign function-key support to separate the two
styles of function keys better, but leaving the choice still controlled
by the sunKeyboard resource. Partway through that, I was asked to do
similar cleanup and redesign of the backspace and delete key handling,
e.g., the ptyInitialErase resource. Because it is a redesign, I chose
to not make the keyboard differences between the old and new xterms
completely compatible. If you were to run both on the same system, one
or the other would have some problems with the editing keypad or the
backspace/delete keys which would be addressed by the popup-menu
selections.
For example, at this time (2001/9/4):
* Debian stable is xterm-88c, which should be identical to the
XFree86 3.3.6 version, but is not (there are some label differences
in the resource-file, but nothing interesting relative to home/end
keys). And of course, Debian changes the terminfo kbs from ^H to
^?. As noted, the terminfo I wrote for XFree86 3.3.x has an error.
Setting
*sunKeyboard: true
in the app-defaults file fixes the problem with xterm-88, which was
that I documented in the terminfo the behavior with that resource
set. Similarly, setting
*backarrowKey: false
is one way to address Debian's change to kbs.
* Debian unstable is xterm-149. Other than omitting the color
resources from the app-defaults file, I see that it sets
*backarrowKeyIsErase: true
which would not affect the home/end keys. (The color resources are
redundant, so that is not a problem either).
Here is a resource file which I tested with xterm-88c, xterm-149 and
xterm-158, using $TERM set to xterm-debian:
! $Id: xterm.faq.html,v 1.169 2012/02/05 11:58:56 tom Exp $
! Settings to make xterm-88c work as expected for Debian.
!
! Patch #88 was the basis for XFree86 3.3.1 xterm. There were a few
additions
! through patch 88c, to incorporate the ptyInitialErase resource. D
ebian uses
! the VT220-style keyboard, which at #88 was the xterm-xfree86 termi
nfo entry,
! with one change: kbs changed from ^H to ^?.
!
! After patch 88, I started work on keyboard changes. The result wa
s that the
! xterm-xfree86 terminfo entry was set to the PC-style keyboard, and
I added
! xterm-vt220, which corresponded mostly to the older (patch-88) ver
sion of the
! xterm-xfree86 terminfo entry.
! The terminfo with patch #88 assumed sunKeyboard was set (actually
a bug, but
! also assumed in Debian).
!
! A different problem (addressed after patch #88) is that if you wan
ted to use
! a VT100/VT220-style numeric keypad's escape sequences, you had to
have
! NumLock set. Otherwise, in keypad application mode, the keys woul
d transmit
! only the PC-style escape sequences corresponding to the key labels
, e.g., the
! page-up string rather than the escape sequence for keypad-9.
XTerm*sunKeyboard: true
! These settings overlap to some extent (backarrowKeys says to send
a 127 for
! the "backspace" key, and ptyInitialErase says to use the pty's ini
tial sense
! of the erase character, which is reported to be the same on Linux)
.
XTerm*backarrowKey: false
XTerm*ptyInitialErase: true
Why can't I use the cursor keys in (whatever) shell?
VTxxx (VT100 and up) terminals may send different escape sequences for
the cursor (arrow) keys depending on how they are set up. The choices
are referred to as the normal and application modes. Initially, the
terminal is in normal mode.
VTxxx terminals are usually set up so that full-screen applications
will use the cursor application mode strings. This is good for
full-screen applications, including legacy applications which may have
hard-coded behavior, but bad for interactive shells (e.g., ksh, tcsh,
bash) which use arrow keys to scroll through a history of command
strings.
To see the difference between normal/application modes, consider this
example:
* In normal (non-application) mode, the terminal transmits a
down-arrow as \E[C, which happens to echo as a down-arrow.
* In application mode the terminal transmits \EOC, which echoes as C.
That is because the \EO is the SS3 control, which says to use the
character from the G3 character set for the next cell.
Since termcaps and terminfo descriptions are written for full-screen
applications, shells and similar programs often rely on built-in tables
of escape sequences which they use instead. Defining keys in terms of
the termcap/terminfo entry (e.g., by capturing the string sent by
tputs) is apt to confuse the shell.
Depending on the terminal type, the keypad(s) on the keyboard may
switch modes along with the cursor keys, or have their own independent
modes. The control sequences for these are independent of the ones used
for cursor-addressing, but are grouped together, e.g., as the terminfo
smkx and rmkx capabilities. Terminfo entries are written assuming that
the application has initialized the terminal using the smkx string
before it is able to match the codes given for the cursor or keypad
keys.
Alt-keys do not work in bash
See Alt-keys do not work in bash.
Colors and other graphic rendition
My terminal doesn't recognize color
First, ensure that you have set up xterm to render color. Modern xterm
renders color only if you have set resources to do this; the default
behavior is monochrome to maintain compatibility with older
applications. The manual page describes these resources. I set them in
my .Xdefaults file.
Even if you set the resources properly, there may be another
application running which prevents xterm from allocating the colors you
have specified. But you should see a warning message for this.
Check the terminal description, to see if it is installed properly,
e.g., for ncurses, which uses terminfo.
Finally, some applications (that do not interface properly with
terminfo or termcap) may need the environment variable $COLORTERM to be
set.
What $TERM should I use?
XTerm provides in its sources both terminfo and termcap files. They are
designed to allow scripting to override the most common choices, e.g.,
the backspace key.
The xterm-color value for $TERM is a bad choice for modern xterm
because it is commonly used for a terminfo entry which happens to not
support bce. Complicating matters, FreeBSD (after dithering for a few
years on the matter) introduced a bastardized version which implies the
opposite sense of bce, (because it uses SGR 39 and 49), but does not
set it. After lengthy discussion, FreeBSD began using the terminal
descriptions which I've written.
The most recent XFree86 version's terminal description corresponds to
xterm-xfree86 (also distributed with ncurses). I have continued to make
changes; the most recent version is simply named xterm-new (also
distributed with ncurses).
The term "bce" stands for "back color erase". Terminals such as modern
xterm and rxvt implement back color erase, others such as dtterm do
not. (Roughly half of the emulators that I know about implement bce).
When an application clears the screen, a terminal that implements back
color erase will retain the last-set background color. A terminal that
does not implement back color erase will reset the background color to
the default or initial colors. Applications that paint most of the
screen in a single color are more efficient on terminals that support
back color erase. Inevitably, there are tradeoffs and issues with
standardization of the feature as noted in the ncurses FAQ.
Unsurprisingly, ncurses supports xterm's behavior.
Curses libraries that support color know about bce and do the right
thing – provided that you tell them what the terminal does. That is the
whole point of setting $TERM. The "xterm-color" description distributed
with ncurses does not list bce, because it was applied originally to a
terminal type which does not implement back color erase. It will "work"
for modern xterm, though less efficient. Some other applications such
as the slang library have hardcoded support for terminals that
implement back color erase. Given the "xterm-color" description, those
will be efficient – and fortuitously work. However, slang (through
version 1.4.0) did not work properly for the terminals that xterm-color
was designed for. See this page for an example of (n)curses and slang
running on dtterm. That bug in slang is reported to be fixed for
succeeding versions, though your application may require changes to use
this fix. (The demo which comes with slang to illustrate the use of bce
does not work properly, for instance).
The xterm-color value for $TERM is also (for the same reason) a bad
choice for rxvt, but "works" due to the large number of hard-coded
applications that override this.
Some people recommend using xtermc. That is installed on Solaris.
However, it does not match any xterm in current use. (Apparently it was
written for an obsolete version on Unixware). The colors work, true,
but the mouse will not, nor will the function keys.
Reverse video is not reset
When running less or other programs that do highlighting, you see the
highlighting not turned off properly.
This may be due to incompatible terminal descriptions for xterm. With
XFree86 3.2, I modified the terminal description for XFree86 xterm to
use the VT220 (aka ISO 6429) controls that allow an application to turn
off highlighting (or bold, underline) without modifying the other
attributes. The X Consortium xterm does not recognize these controls.
If, for example, you are running an older xterm and rlogin to a system
where the newer xterm has been installed, you will have this problem,
because both programs default to $TERM set to xterm. The solution for
mixed systems is to install the newer terminal description as as a
different name (e.g., xterm-color) and set the termName resource
accordingly in the app-defaults file for the system which has the newer
xterm.
However – see above.
My colors changed in vim
Some vim users may notice their colors change after updating to patch
238. Before, some text would display in a dark color using a bold font.
Now, it displays in a bright color and normal font.
This is not a bug, but the result of a feature tcap-query which was
added for vim in 2000. Several vim users requested that it be enabled
by default in the configure script. It allows vim to ask what
characters the different function keys actually send, eliminating the
chance that the termcap does not match.
Vim also asks how many colors the terminal supports. Since patch 148,
xterm has responded with the number of distinct colors that it can
display. By default, that is 16 (8 ANSI colors with bright counterparts
for displaying PC-style "bold" text).
The interpretation of this depends on the application: termcaps do not
tell how to display more than 8 colors. But vim understands how to tell
xterm to display using 16 colors. It makes a difference when displaying
bright colors. Vim has a table of 16 color names ("dos-colors"), which
one can use to define parts of the color scheme. If the terminal
supports only 8 colors (colors 0-7), vim uses the bold attribute to
simulate colors 8-15.
Changing the color scheme to use bold where it is wanted will make the
colors work as before – and work consistently with other terminals.
Aren't bright colors the same as bold?
No.
Actually, "bold" happens to be whatever the terminal shows when it is
sent the control-string that says "show bold".
The standard (ANSI aka ISO-6429 or ECMA-48) says no more than that.
ANSI specified eight (8) colors. In fact, ANSI did not specify the
appearance. That is an implementation detail.
XTerm can be configured to use colors 8-15 for displaying bold text. Or
it can be configured to use those colors as part of a 16-color scheme
(a feature of aixterm). They use different control strings. When xterm
is configured to use the 16-color scheme, it displays bold text by
relying on the font to show "bold" (usually thicker characters).
By default, colors 8-15 are brighter versions of colors 0-7 (with some
special handling for blue). But again, xterm is configurable and you
can use anything that you like for the numbered colors.
Can I set a color by its number?
Well, yes: you can set a color in several ways:
* using the color name
* using an RGB value
* selecting an index from the color palette
That last (an index) is what some people think of as the color number.
The short answer is that you can find on the web tables of colors and
match them up to the “color number”. But the number itself has no
meaning.
In my reply to tput setaf color table? How to determine color codes?, I
noted
You may find this question/answer helpful as well: RGB values of the
colors in the Ansi extended colors index (17-255)
although both question and answer raise additional questions. This FAQ
is the logical place to answer those questions.
Presumably you are reading this to better understand how xterm works.
But you may be interested in the way in which other terminals emulate
xterm. If so, this explanation may help as well.
The long answer is that the correct mapping depends on the terminal —
other terminals do not necessarily match xterm.
From a shell script, you might use tput with a parameter to an escape
sequence referred to as setaf in the terminal description. tput
attaches no particular meaning to the number. That actually depends
upon the particular terminal emulator.
A while back, ANSI defined codes for 8 colors, and there were two
schemes for numbering those. The two are seen in some terminal
descriptions as the pairs setf/setb or setaf/setab. Since the latter
has the connotation of "ANSI colors", you will see that used more
often. The former (setf/setb) switched the order for red/blue as noted
in Why are red/blue interchanged?, but in either case, the scheme was
established for just numbering the colors. There is no predefined
relationship between those numbers and RGB content.
For specific terminal emulators, there are predefined color palettes
which can be enumerated easily enough — and can be programmed using
these escape sequences. There are no relevant standards, and you will
see differences between terminal emulators, as noted in I don't like
that shade of blue.
However, convention is often confused with standards. Because xterm has
been around a while, it is regarded as a standard by some.
XTerm had color support before I began working on it at the end of
1995. Some of this was mentioned in XFree86's changelog:
XFree86 3.1.2Be (10 January 1996)
203. Major xterm cleanup (including prototyping), and fixes to the colour
code (Thomas E. Dickey).
XFree86 3.1.2a (23 September 1995)
14. Colour support for xterm (David Wexelblat).
13. Fix usage of $LINES and $COLUMNS by xterm on SVR4 (David Wexelblat).
and some was not:
* The “dynamic colors” feature came from a patch written by Erik
Fortune (at SGI). Someone applied this to the XFree86 sources
(probably early 1995).
Since X11R4, xterm had colors for foreground and background in the
VT100 and Tek4014 widgets, as well as cursor- and mouse-colors
which could be set via resources. But those were static. The
dynamic colors feature allowed those colors to be set via escape
sequences.
* “Colour support” was a set of changes for ANSI color. It might have
been based on a patch (said to be of unknown authorship) for X11R5
xterm incorporated into a program called color_xterm. Raymond's
comment in terminfo.src implies that this program was distributed
earlier; however the copy of color_xterm-alpha4 which I have at
hand has file modification dates starting in December 1995.
Wexelblat's commit is an earlier non-patch use of the feature for
xterm.
Both were probably due to Tom Weinstein (also at SGI) in 1992,
which you can find in the historic Linux archive. The README.color
file in this earlier color_xterm says
2) Added ISO 6429 support for color text. You can set the foreground
and background color for text using SGR. For example, to make the
foreground red, you do: "^[[31m". The values from 30 to 37 set
foreground, those from 40 to 47 set background. The default colors
are:
0) black 1) red 2) green 3) yellow 4) blue 5) magenta
6) cyan 7) white
These are settable with the resources "color0" to "color1"
Aside from README.color, there was no documentation. The terminal
description was unmodified.
Thus, from the start there were two types of color support in xterm.
ANSI colors treats the available colors as an array (its palette) which
can be programmed, while dynamic colors applies a single color to a
feature.
There have been some changes since the color_xterm in 1992:
Resource 1992 1995 2016
color0 Black black black
color1 Red red3 red3
color2 Green green3 green3
color3 Yellow yellow3 yellow3
color4 Blue blue3 blue2
color5 Magenta magenta3 magenta3
color6 Cyan cyan3 cyan3
color7 White gray90 gray90
color8 gray30 gray50
color9 red red
color10 green green
color11 yellow yellow
color12 blue rgb:5c/5c/ff
color13 magenta magenta
color14 cyan cyan
color15 white white
colorUL yellow foreground
colorBD white foreground
colorRV foreground
colorIT foreground
In development of xterm over the past 20 years, we
* incorporated ANSI (8) colors,
* adapted the aixterm feature (16) colors,
* added extensions for 88- and 256-colors.
Much of that has been adopted by other developers for different
terminal emulators. That is summarized in Why not make "xterm" equated
to "xterm-256color"?.
As hinted by the table, the 16-color extension was partly implemented
in xterm by late 1995, using the scheme of Linux console: bold fonts
are shown as brighter equivalents of the ANSI 8 colors. Unlike the
Linux console, xterm can use bold fonts and (aside from providing
similar appearance to the Linux console for programs such as dialog)
there was no reason to pretend that bold and bright were synonymous.
The colorUL and colorBD features are part of this discussion because I
incorporated those into the indexing scheme for colors. More on that
later.
First, deal with the 256- and 88-color extensions.
The reason for 256 colors is that the index would fit in a byte.
Larason's scheme was simple enough:
* the existing 16 colors
* a color cube (6x6x6 is 216, which is the largest cube no larger
than 256).
* a grayscale "ramp", using the remaining 24 entries.
The xterm source-code includes scripts for demonstrating the colors,
e.g., using the same escape sequences that tput would use:
* patch #94 (1999/03/27) added 8colors.sh, 16colors.sh
* patch #111 (1999/07/10) added 256colors.pl and 256colors2.pl
* patch #115 (1999/07/18) added 88colors.pl and 88colors2.pl
I added the scripts in patch #94 because of some user comments that
there were scripts of that sort available, that there were some
deficiencies in those, and and it would be nice to have some good
examples in xterm's source. Coincidentally, that gave Todd Larason and
Stephen P Wall a starting point for the changes to support 256- and
88-colors.
The 256-color extension came first. 88-colors (using the same control
sequence) came next, to reduce the amount of memory needed. XTerm
stores both foreground and background color indexes for each cell on
the screen. That is two bytes, which doubled the amount of memory used
by xterm for the scrollback. More important, however, was the number of
entries in the colormap. With 256 colors, 65536 entries might be used,
but 88 colors use at most 7744 entries. In the late 1990s, inexpensive
displays were far less capable, requiring workarounds to get acceptable
performance.
The 256- and 88-color schemes (a 16-color table of ANSI (or aixterm)
colors, followed by a cube and then a grayscale “ramp”) are similar. An
intermediate 157-color scheme could have been provided,
88 157 256 Usage
16 16 16 ANSI/AIX
64 125 216 cube
8 16 24 grayscale "ramp"
but the savings in the colormap would be less compelling:
Colors Size Bits
88 7744 13
157 24649 15
256 65536 16
Like the aixterm 16-color extension, these colors are stored in an
array. Unlike aixterm (whose developers invented a new set of escape
sequences not found in ANSI or ECMA-48), we used sequences found in
ECMA-48: SGR codes 38 and 48. However, the feature evolved:
* The default color palette for xterm uses header-files generated
using scripts similar to the ones provided for demonstrations
(patch #112).
The first 16 colors (except for blue) use names in the X rgb.txt.
* The X libraries cannot handle enough resources to specify all of
the 256 colors as well as other features in xterm.
Starting with patch #129, I made the resource settings for colors
past the first 16 a compile-time option. If you prefer to have the
colors as X resource values, you lose UTF-8. Since xterm accepted
escape sequences for setting the palette, this was not a problem.
* Steve Wall modified the palette in 2002 (patch #166), making it a
little brighter.
* We used semicolon (like other SGR parameters) for separating the
R/G/B values in the escape sequence, since a copy of ITU T.416
(ISO-8613-6) which presumably clarified the use of colon for this
feature was costly.
Using semicolon was incorrect because some applications could
expect their parameters to be order-independent. As used for the
R/G/B values, that was order-dependent. The relevant information,
by the way, is part of ECMA-48 (not ITU T.416, as mentioned in Why
only 16 (or 256) colors?). Quoting from section 5.4.2 of ECMA-48,
page 12, and adding emphasis (not in the standard):
Each parameter sub-string consists of one or more bit combinations
from 03/00 to 03/10; the bit combinations from 03/00 to 03/09
represent the digits ZERO to NINE; bit combination 03/10 may be used
as a separator in a parameter sub-string, for example, to separate
the fractional part of a decimal number from the integer part of
that number.
and later on page 78, in 8.3.117 SGR – SELECT GRAPHIC RENDITION,
the description of SGR 38:
(reserved for future standardization; intended for setting character
foreground colour as specified in ISO 8613-6 [CCITT Recommendation
T.416])
Of course you will immediately recognize that 03/10 is ASCII colon,
and that ISO 8613-6 necessarily refers to the encoding in a
parameter sub-string. Or perhaps you will not.
It took several years for this to become an issue. The developers
of other terminal emulators were not the ones who first complained
about it. In fact, though the order-dependence was mentioned, no
one pointed to a specific program which was affected. Still, it was
a known problem.
Later, in 2012 (patch #282), I extended the parser to accommodate
the corrected syntax. The original remains, simply because of its
widespread use. As before, it took a few years for other terminal
developers to notice and start incorporating the improvement. As of
March 2016, not all had finished noticing.
On releasing ncurses 6.1 in 2018, I used the corrected syntax in
the xterm-direct terminal description, and also provided working
examples for the other terminals which supported the direct color
feature. Some of those still did not support the standard syntax
for the control sequences:
+ xterm+direct is the building-block for standard terminals
+ xterm+indirect is a building-block for nonstandard terminals
Still later, in 2020, a user's request prompted review of this
area:
+ One of the other terminal developers had implemented a new
feature using xterm's original semicolon delimiters.
+ That created a problem for this user because the same string
sent to both terminals would color text on the other terminal,
but reset colors on xterm.
+ That happens because (unless xterm were specially modified),
xterm cannot tell that the new feature has subparameters which
are supposed to be used for setting colors.
+ The feature itself is nonstandard, using a code marked in
ECMA-48 for future standardization, so there is no reason to
modify xterm.
+ As noted in the ncurses FAQ Why not just use TERM set to
"xterm"?, sometimes xterm's terminal description uses features
not supported by other terminals.
+ ncurses has correct terminal descriptions for xterm and other
terminals (such as the one with the nonstandard feature).
+ Providing a terminal description using the nonstandard
semicolon for delimiting subparameters encourages users to
stumble into this problem.
+ Going forward (e.g., xterm patch #357), these terminfo
building blocks are used in ncurses:
o xterm+256color2 is the building-block for standard
terminals
o xterm+256color is a building-block for nonstandard
terminals
As others incorporated the xterm 256-color feature, the ability to set
the palette was usually not done before announcing that a program had
the 256-color feature. Others acquired the ability to set the palette
after a lapse of years. As an exception, Geoff Wing (rxvt developer)
implemented the complete feature in August 2002 (release 2.7.9). Any
xterm-compatible implementation with support for 256-colors
automatically supports 88-colors, since the palette is modifiable,
which makes comments such as this at best badly informed.
A few non-xterm applications may support the feature, e.g.,
* PuTTY (Windows)
* iTerm2 (MacOS)
* teken (FreeBSD)
though the results may not be satisfactory. Here are screenshots for
88- and 256-colors which I made in February 2014 while discussing
deficiencies of the FreeBSD console emulator:
teken with 88-colors
teken with 256-colors
XTerm stores the colors for colorUL, etc., at the end of the color
array used for ANSI, 16-, 88- and 256-colors. An application can modify
the colors using OSC 4, which does not reduce the range available for
the SGR 38/48 index used for selecting colors (underline, bold, reverse
— and italics — all have their place in the video attribute fields).
Like dynamic colors, this was a feature found in XFree86 but not in
X11R5 or X11R6. According to David Dawes, some people liked the
feature. Mark J Olesen incorporated the same into rxvt mid-1996, and I
added the other two attributes. However, it was mainly popular with Red
Hat users who wanted to color their manpages. After Werner Lemberg
changed groff behavior in 2001 to color manpages, this feature is not
that well known.
Finally, there are the default foreground and background colors set
using SGR 39/49.
If one wants to enumerate the colors which can be set by index in
xterm, there are multiple indices that are needed:
* SGR number (for the 8 ANSI colors, the extra 8 aixterm colors and
the default colors)
* SGR 38/48 with (index) parameter (for the 88-colors and the
256-colors, keeping in mind that those include the first 16 ANSI
and aixterm colors)
* OSC 4 with (index) parameter (colored video attributes)
* OSC numbers 10-19 (dynamic colors)
The sample scripts in xterm's sources demonstrate these features. Some
are written in POSIX shell, the remainder are in Perl.
I don't like that shade of blue
Nobody does. But there are no universal solutions.
If your terminal (or the application running in it has a dark
background, then darker blues are hard to see. With a light background,
yellows are hard to see.
The available standards do not help: there are no standards for
terminal colors. Here is an illustration which I made in reply to a bug
report, contrasting different choices for blue, against some of the
other terminals which (were said to) provide "standard vt100 colors":
Contrasting blue in terminal emulators
Of course, anyone developing a terminal emulator already knew that
vt100's never did do colors.
Ultimately it is up to the application running in a terminal to enforce
the colors it needs. XTerm merely provides the best compromise on
default visibility that I and my users have found.
Why doesn't xterm support italics?
Well, actually it does and it doesn't.
You can display "any" font using xterm (though proportional fonts may
be disappointing).
But xterm has specific types of graphic rendition that it will do. If
you want italics, then xterm has an option (italicULMode) to use that
rendition instead of underlining. That is the usual typographic
alternative, though of course some people want both at the same time.
However, standard curses does not support italics. Few terminals do
this reliably, so it was disregarded long ago, never was supported
except for low-level applications (in terminfo). No bit was reserved in
the curses header for adding italics for high-level applications. (As a
special case, ncurses was modified to provide partial support, but
programs using this feature will not work with other implementations).
XTerm stores each cell of the display in fixed-size structures. One
byte stores the graphic rendition. XTerm is using all of the bits in
this byte for its VT220 emulation:
Mnemonic Bit Description
INVERSE 0 show cell reverse-video
UNDERLINE 1 show cell underlined
BOLD 2 show cell as bold
BLINK 3 show cell as blinking
BG_COLOR 4 use background color
FG_COLOR 5 use foreground color
PROTECTED 6 character cannot be erased
CHARDRAWN 7 character has been drawn here on the screen
While additional bytes could be added to each cell, the cost to the
typical user has so far not been in line with the usefulness of the
feature.
For those who are not constrained by cost, since patch #305 xterm
provides an experimental compile-time option to support italics. The
main reason for implementing this is to be able to test the italics
feature added in ncurses (patch 5.9.20130831):
* this increases the size of the attributes data.
* the feature requires some overhead for font-switching (treating
italics as "rare")
The increase in size is not entirely wasted. The SGR attributes for
dim, strike-out, and double-underscore also are implemented. However,
the last two are not in the portable terminfo definition (from X/Open),
and are not supported in the higher-level curses interface (there is no
A_STRIKE for that reason).
Here are screenshots showing the ncurses test-program displaying video
attributes (including italics). The first uses bitmap fonts:
ncurses – video attributes with bitmap-font
and the second uses a (same size) TrueType font:
ncurses – video attributes with TrueType font
"grep --color" does not show the right output
GNU grep (version 2.5) introduced a --color option.
It does this for each highlighted match:
1. it writes the text up to (not including the match)
2. it writes an ANSI color control control sequence
3. it writes the matched text
4. it writes a control sequence to clear to the end of the line
5. it writes an ANSI control sequence to reset graphic rendition.
6. repeat this process until the entire line is written.
One problem is in the second and fourth steps. If the preceding text
brought us up to the last column, then xterm (and any VT100-compatible
terminal) is waiting for graphic text to wrap to the next line. Any
controls would take effect on the current column position. Newlines are
ignored while in this state.
However, if xterm gets a control sequence while waiting to wrap to the
next line, it will update the screen according to that control. Then it
is ready to accept more data. But at this point, it is no longer
waiting to wrap; the special case is for newline versus graphic
characters. For instance, backspacing clears the state (vttest
illustrates this). So the data starts to write at the current column
(the last one on the line), rather than at the beginning of the next
line. In that case, grep's output will not look right.
Here are some relevant bug reports:
* Debian #456943 - grep: incorrect display with color and wrapping in
some terminals
* Fedora #1006310 - xterm does not print a character if the character
is last on a row and a color-change ANSI sequence follows
* Novell #148844 - terminal text wrapping bug
That description of wrapping is odd, say more?
This is one of the aspects of the so-called "vt100 glitch", as
mentioned in the terminfo manpage:
Terminals which ignore a line-feed immediately after an am wrap,
such as the Concept and vt100, should indicate xenl.
When the terminal reaches the right margin, it is in a special state
where it ignores tab characters and other formatting controls (carriage
return and newline), and in effect is expecting only printable
characters to wrap to the next line.
Without it, it is misleading to refer to a terminal as a vt100
emulator. After all, it is a well-known feature named for the VT100.
The applicable standards (ISO-6429, ECMA-48) do not go into enough
detail to address this sort of behavior, so the other terminal
emulators can be referred to most accurately as ANSI terminals (if they
obey the other guidelines).
In 2004, I added a test-screen to vttest to demonstrate this. It was in
response to someone who insisted that xterm was wrong and one of those
other terminal emulators was "right". I investigated, found that the
behavior had not changed in xterm at least since the early 1990s, and
that it matched the description of behavior from the DEC manuals. One
of my users verified the correctness of the test on a VT520.
Reviewing the results with xterm-alikes or less ambitious "vt100
emulators" in mid-2013:
* xterm, kterm, mlterm, some operating system consoles are consistent
with the VT100 behavior.
* rxvt, screen, putty (pterm), konsole, vte (gnome-terminal,
xfce4-terminal) are not consistent with VT100 (and behave
differently compared to each other).
I included screen here because it claims to be a vt100 emulator,
and putty since it claims to be an xterm emulator. I did not
include tmux, because it does not make either claim.
* mrxvt does not get to that screen; it resizes its window to a
single line.
In the vttest page, I have provided screenshots to illustrate these
points.
Since 2013, Mattias Engdegård created a test program to explore this
area, citing DEC's internal standard document for terminals (DEC STD
070 Video Systems Reference Manual). That document refers to this as
the last column flag.
Revisiting this in 2019, no improvement has been observed in the
problematic programs from 2013. A VTE user gave this example
#!/bin/bash
echo -e "\e[2J"
echo -e "\e[1;79Hx\b\vx\b\vx\n"
echo -e "\e[5;80Hx\b\vx\b\vx\n"
In this case, DEC's documentation for the last column flag mentions
that cursor-positioning resets the flag. Because xterm takes that into
account (while the others from 2013 do not), the example will show
different results. Markus Schmidt provided a screenshot which
demonstrates that DEC's documentation is correct and that some terminal
emulators (e.g., xterm, zoc, MacOS Terminal, st) implement this detail
in the same way that the hardware terminal did:
screenshot of last column flag with cursor positioning
That color scheme is odd, say more?
Occasionally someone questions the behavior of the bce (background
color erase) feature in xterm, and mentions that some DEC terminal did
not behave that way with ANSI colors.
First off:
* Aside from the VT525, DEC terminals had no support for ANSI colors.
* Likely, they were thinking of a terminal emulator which supported
colors. A while back, there was more than one which said they were
a “VT340” and the misconceptions began. Not all of those behaved
the same.
Some developers were aware of this, others were not. The
comp.os.vms newsgroup thread How to setting color in code for a VT
terminal shows both.
* From the outset, modern xterm was a VT100 or VT220 with ANSI
colors. No technical manual was available for a VT525 at the time.
Lacking a technical manual, information about a VT525 was no more
reliable than the statements about a VT340.
The design used for xterm imitated Linux console, which itself came
about from different people (see this page for some background).
The VT525 programmer's reference manual is vague on the details (ANSI
color is mentioned in a fraction of one percent of the manual), but the
DEC standard for terminals is clear that it would not implement bce:
any erase command will reset the video attributes. It documents ANSI
color in the section on video attributes without mentioning a special
case. Color would be reset as well.
Odd behavior
Why can't I select/paste in xterm?
When an application sets xterm to any of its mouse tracking modes, it
reserves the unshifted mouse button clicks for the application's use.
Unless you have modified the treatment of the shifted mouse button
events (e.g., with your window manager), you can always do select/paste
by pressing the shift key while clicking with the mouse.
This is all done using the translations resource (see the Default Key
Bindings section in the manual page).
Why can't I select/paste to/from other programs?
Whether you select text in xterm and paste into another window, or the
reverse, the X client in which you have selected text may provide the
data in different formats and different containers:
formats
Originally (and by default) xterm made the selected data
available with ISO-8859-1 encoding (Latin-1). Since patch #101
(1999), it has provided it also in UTF-8.
Regarding the type of data:
+ X11R4's ICCM documented "string" selection data with
ISO-8859-1, while
+ X11R6 documented "compound text" (another name for multibyte
encoding, without specifying what encoding).
+ Selection data using UTF-8 was an extension by XFree86.
The client holding the selection advertises the formats that it
can provide, and other client(s) ask for it using one of those
formats.
Xterm can ask for UTF-8 even if it is not configured to use
UTF-8. In that case, it converts (a small number of) useful
characters to their ASCII or VT100 line-graphics equivalents,
and uses a "#" character for those which cannot be converted.
containers
By default, xterm follows the Inter-Client Communication
Conventions Manual (ICCM). That dates back to X11R4 in 1989,
with minor updates in 1996 for X11R6. The copyright for ICCM 1.0
is 1988/1989, making it slightly older than Microsoft Windows.
The ICCM specifies "selection atoms" which are maintained by the
X server. According to the ICCM:
The selection named by the atom PRIMARY is used for all commands
that take only a single argument and is the principal means of
communication between clients that use the selection mechanism.
and
The selection named by the atom CLIPBOARD is used to hold data that
is being transferred between clients, that is, data that usually is
being cut or copied, and then pasted.
xterm uses PRIMARY by default. The default translations also
update something called CUT_BUFFER0 (also part of the ICCM).
Unlike the PRIMARY selection, a cut buffer can hold only "type
STRING and format 8" (which happens to be ISO-8859-1). That
sounds like a drawback, but on the other hand, cut buffers are
persistent, while the PRIMARY selection is not. An X client can
provide data using the PRIMARY selection only as long as it
holds the selection.
If xterm does not own the selection, it cannot supply the data (and you
cannot select/paste). Initially, xterm held the PRIMARY selection only
as long as the text was highlighted. Another application could assert
the selection, but generally losing the PRIMARY selection in xterm was
the same as losing highlighting. That has been improved, e.g., using
the keepSelection resource in patch #230 (2007), as well as refinements
to retain highlighting when it updates other parts of the window.
A more likely reason for failing to select/paste is that the other
application may not use the same selection atom (container). In the
mid-1990s, Netscape set out to compete with Internet Explorer. Part of
that involved copying many aspects of the way Internet Explorer worked,
including the way it worked with the Microsoft Windows clipboard.
Netscape on non-Windows platforms, "of course" assumed the clipboard
was the way to do things, and used the X11 clipboard rather following
the ICCM. (The way it used the X11 clipboard was also not in line with
the ICCM, but it was "close").
Not all applications followed Netscape and its descendents, making it a
nuisance if one wanted to select/paste text to/from the web browser.
Since patch #209 (2006), xterm has provided a workaround: a menu entry
(and resource selectToClipboard) which changes xterm's behavior for a
special token SELECT in its default translations. If the resource is
true (or the menu item enabled), xterm provides its selection to the
CLIPBOARD. A menu item is provided, of course, since many applications
follow the ICCM. In the default translations, these lines use SELECT:
Shift <KeyPress> Select:select-cursor-start() \
select-cursor-end(SELECT, CUT_BUFFER0) \n\
Shift <KeyPress> Insert:insert-selection(SELECT, CUT_BUFFER0) \n\
Why can't I select tabs in xterm?
This issue was noted early on, here in 1997.
XTerm is copying from the screen, which stores only printable
characters. That includes spaces and line-drawing characters. But tabs
are special; they are used for more than one purpose.
If the screen is cleared in some part, that stores nulls. Cursor
addressing does not fill in nulls as it jumps around, though xterm does
supply blanks for the most useful cases, especially when getting data
for a selection.
Full-screen programs such as text-editors tend to write in random
fashion, and generally do not print nulls to the screen. Curses on the
other hand, may supply tabs where you thought there were none. Also,
the terminal driver can expand tabs (and often is set to do this by
default).
So the whole thing is unreliable: unless you make special arrangements
for each of the programs running inside xterm, you would often get a
tab when you expect, and vice versa.
For the special case where your expectations would match the available
data, it is solvable. There are basically two ways it could be done:
* set a bit in each cell's data which says it was skipped over via a
tab. The complication is that xterm is using all of the flag bits
in each cell.
* store literal tabs and nulls to be interpreted later – both by the
display and the selection logic.
As of 2010, a few other terminals did implement this feature. But the
reason that it's been low-priority is that it's of very limited
usefulness when copying between terminal sessions (and for that matter,
from other clients).
Can bracketed-paste solve my problems?
That depends. Bracketed-paste only gives an application a clue that the
input from the keyboard is being pasted rather than typed. It was
intended to help with the autoindent feature in text editors. But not
all programs recognize the feature (see this page for more
information).
FVWM does weird things when I try to resize xterm
I have an old (3.1.2G) bug report for xterm which may be related to the
second (3.9s) problem:
* Steven Lang <tiger@ecis.com> reports a problem with extra resize
events for xterm.
When I change font size often I will get the double-refresh, and
when that happens the text program gets 2 resize events.. Running a
quick test, I got this: Going to a bigger font, it got a 53x20
resize, then a 80x24 resize. Going to a smaller font, it got a
120x27 resize, then a 80x24 resize.
Earlier I made a mention of changing font size in rxvt (And xterm
does it to) causing 2 resize events. Well I just happened to do it
in fvwm (Instead of fvwm 95) and found it seems to be a 'feature'
of fvwm95, not XFree86 as I'd initially assumed.
* Stephen Marley <stephen@memex.com> reports a problem with the
active icon (from X11R6.3 xterm):
Using the XFree86 xterm-53 with the active icon feature on, I get
some problems resizing where the xterm window shrinks as small as
possible and won't stay at whatever size you set it thereafter.
Comment out the PixmapPath and IconPath from your .fvwmrc file to
disable the fvwm icons and restart the WM. Start an xterm. Iconify
xterm and maximize it again. Use resize button or corners to resize
the xterm.
The xterm now shrinks to a tiny size and attempts to resize it
result in it shrinking again.
I've tried this with fvwm 1.23 and fvwm 2.0.46 with the same
results. Olvm, olvwm and twm all behave correctly so it may be a
fvwm problem.
I have not observed the first, but have reproduced the second.
Why doesn't the screen clear when running vi?
This refers to the "alternate screen" feature, which has been used in
its termcap file since 1988. On various systems, this feature may have
been removed, although it has always been in the xterm sources.
The feature is controllable (it can be enabled or disabled). However,
as it was originally conceived, that ability to control it applies only
to programs using termcap.
Under SunOS 4.x, the termcap description for xterm embeds in the ti and
te capabilities a command to switch to xterm's alternate screen (e.g.,
while running vi), and return to the normal screen on exit. This has
the effect of clearing the screen. The corresponding terminfo symbols
for ti and te are smcup and rmcup, respectively.
Beginning with Solaris 2.x, the terminfo description did not use the
alternate screen (it is a matter of preference after all), so that the
text from vi remains on the screen after exit. Sun patched the X11R5
terminfo description to omit the smcup and rmcup capabilities. However,
Sun began distributing modern xterm on the freeware companion (a CDROM)
beginning with Solaris 8. In Solaris 10 for instance, the ncurses 5.6
package provided a usable terminal description for xterm which uses the
alternate screen. Solaris 11 distributes modern xterm (though perhaps
oddly) using an old—unpatched—terminal description.
Because it is in the terminal description, the feature is
configurable...
For example (from Bjorn Helgaas <helgaas@dhc.net>) this procedure adds
these capabilities to the "xterm" terminfo definition on HP-UX 10.20:
cp /usr/lib/terminfo/x/xterm /usr/lib/terminfo/x/xterm.orig
untic xterm > /tmp/xterm.src
echo " smcup=\E7\E[?47h, rmcup=\E[2J\E[?47l\E8," >> /tmp/xterm.src
tic /tmp/xterm.src
In this example, the terminfo strings are a series of operations:
smcup
\E7 saves the cursor's position
\E[?47h switches to the alternate screen
rmcup
\E[2J clears the screen (assumed to be the alternate screen)
\E[?47l switches back to the normal screen
\E8 restores the cursor's position.
However, xterms that are linked with termcap are more flexible in this
area than those linked with terminfo libraries. The xterm program
supports a resource titeInhibit which manipulates the $TERMCAP variable
to accomplish this. It sets the $TERMCAP variable for the client with
the ti and te capabilities suppressed. Systems that use terminfo cannot
do this. If you are running terminfo with the alternate screen controls
in the terminal description, then you can suppress the switching to the
alternate screen by the titeInhibit, but not the associated cursor
save/restore and clear-screen operations.
XFree86 3.9s xterm implemented a different set of controls (private
setmodes 1047, 1048 and 1049) which address this (in addition to the
older set of controls, for compatibility). The new set of controls
implements the entire ti sequence (save cursor, switch to alternate
screen, clear screen) and te (switch to normal screen, restore cursor)
as two control sequences that can be disabled by titeInhibit.
The 1049 code is a refinement of 1047 and 1048, clearing the alternate
screen before switching to it rather than after switching back to the
normal screen. Since patch #90 in 1998 xterm allows you (with a popup
menu entry designed to exploit this behavior) to switch the display
back to the alternate screen to select text from it, to paste into the
normal screen. You can also set or clear the titeInhibit resource using
another popup menu entry (Enable Alternate Screen Switching).
Most other terminal emulators implement only half of the feature. They
recognize the control sequence, but do not provide the ability to
change it at runtime, e.g., using a menu entry. Like any other
half-done implementation, that is a bug which should be reported to the
developers of those programs.
Why doesn't the screen clear when I type control/L?
Control/L is ASCII form-feed. Printers do something with form-feed.
Terminals do not, as a rule (though I agree it would be nice, e.g.,
this).
Interpreting form-feed is normally done by your shell, not by the
terminal emulator. In a quick check:
* bash, tcsh, zsh interpret form-feed by clearing the screen, while
* csh, dash, ksh, mksh, yash do not
VT100s did not respond to form-feed. A few terminal emulators interpret
form-feed (PuTTY and SunOS console), but neither matches VT100
behavior.
Because most people do not see the difference between a form-feed which
they type (and is presumably echoed as a form-feed) versus a form-feed
which is sent from an application to the terminal, this leads to
confusion. Several years ago, I pointed this out as one of the errors
in the C FAQ (notwithstanding Summit's comment, he did not update the
FAQ).
Why is the cursor misplaced after running vi?
Vi and other full-screen applications use the termcap ti/te (terminfo
smcup/rmcup) strings to initiate and end cursor addressing mode. As
mentioned in the discussion of titeInhibit, full-screen applications
can expect the initialization string to save the cursor's position, and
the end-string to restore it.
A few applications (reportedly IRIX 5.x and 6.x vi incorrectly move the
cursor before initializing cursor-addressing. This will cause the
end-string to restore the cursor to its position when it was saved by
the initialization string (typically at the upper left corner of the
screen).
The usual reason is due to the cursor save/restore controls in the
ti/te strings. If your application runs a subprocess which in turn runs
another full-screen application (or when reinitializing the screen
after the shell process), it will save the cursor position again, so
the position which is restored when finally exiting your program is the
last one saved, not the first. Modern xterm (from late 1998, patch 90)
changes the behavior of the cursor save/restore operations so they
apply only to the current screen. That makes it less likely to misplace
your cursor.
Why doesn't the scrollbar work?
Originally xterm was built using imake rather than a configure script.
One feature of imake that is not possible to guess within the configure
script is the wide-prototype compile-time definition NARROWPROTO. When
this is not set properly, the Athena widget scrollbars do not work
properly. xterm's configure script has a fallback case which allows
disabling imake. However, this is moot with the Xorg "modular" build,
whose compiler options are unrelated to imake or older versions of any
libraries that it may distribute. In this case, the configure script
needs some help. Use this option to enable or disable NARROW proto (and
disable imake with the --disable-imake option) to match the whims of
Xorg hackers.
For instance
configure --disable-imake --disable-narrowproto
Can I improve the scrollbars?
Is that a problem with the appearance, or the way they work?
The appearance can be modified (though few do this) by linking with one
of the variants of the Athena widget set (Xaw).
To illustrate, here are a few screenshots:
Xaw (default)
xterm – default scrollbar with Xaw
XawPlus
xterm – scrollbar with XawPlus
Xaw3d
xterm – scrollbar with Xaw3d
neXtaw
xterm – scrollbar with neXtaw
Those variants use the same calling interface, so supporting them is
simple. Adapting to other toolkits would be much more difficult. For
instance (see the discussion of mxterm), replacing the scrollbars may
require replacing other parts from the library to get consistent
initialization and operation. In the case of Motif, it had nothing like
the Athena widget set's popup menus.
Can I improve the scrolling speed?
Several years ago (before 2010) there was a webpage which gave its
author's notion of what constituted a “good” terminal emulator: cat'ing
(sending) a large file to the terminal would complete in minimal time.
Apparently that was the sole interest. Interestingly, its author stated
that xterm was the slowest although the presented data do not show
this. Also, although the page says “Linux” some of the data are for
programs running on Windows. The page spawned a few imitators (with no
better methodology), none was systematic, none did any analysis.
Of course, developers do not do that in practice. The terminal is
useful for interactive tasks. Compiling is best done by redirecting the
build messages to a log file or using a batch process. End users have a
different outlook.
There is more than one factor involved in scrolling speed. Here are a
few:
* When xterm was first written, machines had less memory, and
scrolling back a thousand lines seemed good enough for users.
Internally, xterm stored the current screen and saved-lines in a
large array. It scrolled the array by shifting the entire array by
a given number of rows. For a thousand lines saved-lines (the
scrollback region), that works well enough.
But the saveLines resource allows a full integer, and during the
mid/late-1990s, a few users found that setting the resource to a
million lines made xterm very slow.
Still, the graphics display was fast enough. By the way, xterm uses
the XCopyArea function, and normally (attempts to) display all of
the updates to the screen.
* Later, rxvt came along. It limited the number of saved-lines to a
signed 16-bit integer, i.e., 32767 (and some packagers limited it
to only a few thousand lines), and moved just the pointers to the
line data when scrolling rather than shifting all of the text. It
also uses XCopyArea, noting in its features
/*
* Define to remove support for XCopyArea() support. XCopyArea() is useful
* for scrolling on non-local X displays
*/
/* #define NO_SLOW_LINK_SUPPORT */
Unlike xterm, rxvt did not attempt to display all updates. If it
fell behind, it would discard some of the updates, to catch up.
Doing that had a greater effect on the apparent scrolling speed
than its internal memory organization, since it was useful for any
number of saved-lines. One drawback was that ASCII animations were
somewhat erratic.
* A few other terminal emulators, such as konsole copied the rxvt
feature. Others copied, in turn, from whatever source. As a result,
one cannot compare the speed of different terminal emulators, since
they do not follow the same rules.
* The issue with xterm shifting a large array was a problem which was
addressed by changing all of the pointers to its line data into a
circular array in 2009 (patch #244).
* Even after improving the memory performance of scrolling, rxvt and
its imitators still appeared to scroll faster.
The fastScroll resource added in patch #244 provides a simple
implementation of the rxvt (mis?)feature for xterm.
As implemented, it is rather crude (sometimes xterm — like konsole
— appears to stop, since it is waiting for a new set of screen
updates after having discarded some).
Scrolling speed is only one aspect of terminal speed, but it is easy to
measure. Other aspects (such as the speed with which an application can
change color, move the cursor around the screen, write text in various
places) can also be measured. But comparing terminals based on that
speed can be misleading. When the terminal drops updates to keep up
with an application's speed, the result may be unnoticeable (if the
application is fast enough), or it may not.
For example, running the dots program from the ncurses-examples shows
some interesting misbehavior with gnome-terminal and konsole: both
“choke” at times for a few seconds. The dots program prints colored
cells randomly around the screen, pausing briefly 1% of the time.
However when dots is terminated, it prints the program's notion of the
output rate. In spite of the pauses, the program saw a fairly good rate
of output. Some terminal emulators cannot keep up with dots; one
possible explanation for the discrepancy is that the terminal emulator
discards output (as in the special case of scrolling).
Seeing that raised the question of what variation to expect from
different terminal emulators, to point out which might discard output
to achieve fast scrolling speeds. A simple script showing the elapsed
time to send ncurses's terminfo.src (1.1Mb) a given number of times to
the terminal was used. Here is a table illustrating the differences,
using the available terminal emulators for Fedora 26 and Ubuntu 17 in
November 2017:
Mode Terminal Fedora Ubuntu
1 10 99 1 10 99
Remote gnome-terminal (1) (1) (1) (1) (1) (1)
konsole 0.12 2.10 23.2 0.26 2.65 25.7
mlterm (2) (2) (2) 0.30 3.07 30.4
pterm / putty 0.15 1.42 14.6 0.55 5.66 56.2
rxvt (3) 0.25 2.97 29.5 0.23 3.03 29.5
st / stterm (4) 0.07 0.50 4.40 0.15 1.42 14.4
terminology 0.10 1.00 10.1 0.19 2.01 19.0
urxvt 0.05 0.38 3.24 0.17 1.60 15.7
xterm 0.31 3.50 34.8 0.47 4.41 44.1
xterm + fastScroll 0.09 0.82 8.36 0.39 2.43 22.9
Local gnome-terminal 0.12 1.16 11.4 0.29 3.14 30.6
konsole 0.11 0.82 7.97 0.22 2.17 20.1
mlterm (2) (2) (2) 1.01 7.59 105.
pterm / putty 0.17 1.52 14.6 (5) (5) (5)
rxvt 1.23 11.9 118. 1.75 16.9 166.
st / stterm (4) 0.08 0.61 5.10 0.21 1.63 15.9
terminology 0.09 1.03 10.1 0.43 1.64 16.0
urxvt 0.07 0.53 4.52 0.26 2.41 23.7
xterm 1.77 18.5 178. 2.70 26.5 259.
xterm + fastScroll 0.12 0.96 9.92 0.25 2.36 22.9
Notes:
1. On both systems, gnome-terminal failed to connect remotely.
2. Fedora does not have mlterm.
3. On Ubuntu, the urxvt package hijacks the name “rxvt”, so the “rxvt”
actually tested was rxvt-xpm from the rxvt 2.7.10 package.
4. Fedora has st 0.70, while Ubuntu has version 0.60, which is a
couple of years older.
5. Running locally on Ubuntu, pterm 0.70-1 dumped core.
Regarding the selection of terminal emulators:
* Keeping mind that this is an xterm FAQ, the Linux console (and
Windows console, and PuTTY running on Windows) are off-topic.
* The table mentions programs which at one time or another have set
TERM=xterm.
The actual test does not rely upon the terminal description, nor in
fact on any terminal description. The distinction was made for
their relevance to this FAQ.
* Given that, rxvt 2.7.10 is listed, as well as its descendent urxvt
(rxvt-unicode).
Other variations of rxvt (such as aterm and mrxvt) were considered,
but since much of the related code is identical, not very
interesting.
* Both systems have several variants of the skins for the VTE
library, but for both systems, the developers have a heavy bias in
favor of the GNOME desktop. Comparing the performance of the
various skins would be pointless, since not all are equally
supported (due to the GNOME developers' practice of making
incompatible changes), and would make an unbalanced comparison in
any case.
* The Unix port of PuTTY, pterm is listed. It uses GDK.
Interestingly, performance is better running remotely. In the test, the
machines are not identical:
* The remote system uses a Mac mini-server.
* The Fedora system is a virtual machine using Parallels.
* The Ubuntu system is a virtual machine using Vmware Fusion.
Possibly displaying on the virtual machines does not perform as well as
via XQuartz. But that is a lot of difference to explain. More likely,
the local X server is performing badly on some calls.
* For a while, XCopyArea was a problem, where the Xorg hackers had
degraded its performance radically. While that might still be the
underlying issue, st and urxvt do use that function.
* Another possibility is mentioned in Why is the text in the wrong
place? where the apparent root cause was a server feature which
only implemented parts of the X protocol.
Using the fastScroll feature made xterm performance comparable to the
“desktop” applications. But as usual, with performance data, your
mileage may vary.
Why can't my program read the window title?
The longstanding control sequence for reading the window title is
something that can be abused in special conditions. For novice
(unknowledgable) users, this can be a problem.
XTerm provides resource-settings and menu entries to allow this and
related features to be enabled or disabled. See for example
allowWindowOps The default resource settings in xterm can be overridden
by a packager. However, a knowledgable user can override those default
settings.
It is also possible that an overzealous packager may have crippled
xterm by removing the functionality altogether. (That should be
reported as a bug, to me).
For instance, one of those sent me a "security fix" some years ago,
which deleted most of the control sequences which return data to the
host. It broke the resize program, and selection, among other uses
considered to be benign. In contrast, the same features used in other
terminal emulators are tolerated by the same people, so rather than
being a misguided attempt at fixing security issues, patches such as
that appear to be an attempt at harassment.
Why can't my program set the window size?
Some overzealous packagers, perhaps influenced by the demonstration I
provided, are protecting you against the possibility of your xterm
becoming inaccessible. (That's unlikely...).
You should be able to override it, as noted above via resource settings
or menu entry ("Allow Window Ops").
Why is the text in the wrong place?
Are you using Ubuntu? This was a frequently-reported problem for Ubuntu
users. With other systems, it could occur (as of September 2012), but
is less frequent. But it was an issue with Ubuntu since 2008.
There ware several related symptoms, e.g.,
* text may be the wrong size
* repainting the screen puts text in the wrong place
Here are some of the corresponding bug reports:
* Ubuntu #199285 - xterm crashes when compiz is on
* Debian #467399 - compiz fails to take control of windows
* Ubuntu #378668 - Cursor in terminal behaves badly with special
characters present
* Novell #622936 - xterm: font drawing glitch
* Redhat #583904 - gnome-terminal and xterm show garbled fonts with
compiz enabled (intel graphics)
* Redhat #614542 - xterm graphical corruption when compiz is active
* Ubuntu #635258 - Garbled chars in xterm
* Ubuntu #644943 - xterm fonts get corrupted while typing
* Ubuntu #701160 - /usr/bin/xterm is not functional in natty
* Ubuntu #700477 - Font corruption in xterm under Lucid
* Novell #681359 - xterm: no data shown under the screen program
* Ubuntu #711894 - iconic option does not work with compiz
* Ubuntu #778439 - Typing "exit" in xterm kills X session
* Ubuntu #831336 - running 'xterm' crashes X server
* Ubuntu #841103 - Text has artifacts when typing something else
* Ubuntu #844454 - Garbled chars in xterm (Onieric)
* Ubuntu #1002972 - xterm moves to upper left when clicking titel bar
* Ubuntu #1007722 - xterm doesn't display all the information
Since the problem was not in xterm, all I could do is to help forward
those bug-reports to whatever package owns compiz. What these had in
common is that someone wrote code which was tested against only a small
subset of the X protocol.
Looking for solutions (since compiz was not being fixed), it was
possible to disable compiz. The means for doing this varied with time.
Aside from pointing to the root cause of the problem, there was little
advice that was useful.
* For instance, this comment by Eric Williams suggested that the
problem could be worked around by setting xterm's borderWidth
resource to zero.
* other comments suggested turning off the "desktop effects" or
"animation".
* On my machines using the default Ubuntu desktop, I could see
misbehavior easily in Ubuntu 12.04 using vttest. However, Ubuntu
12.04 provided Ubuntu 2D, which did not show those problems (and
was noticeably faster).
Ubuntu dropped compiz in 2017. Its replacement (GNOME shell) has fewer
bugs.
Sample .Xdefaults Color-Settings for XTerm
This example dates from March 1997:
XTerm*internalBorder: 10
XTerm*highlightSelection: true
XTerm*VT100.colorBDMode: on
XTerm*VT100.colorBD: blue
XTerm*VT100.colorULMode: on
XTerm*VT100.colorUL: magenta
XTerm*VT100.eightBitInput: true
XTerm*VT100.eightBitOutput: true
XTerm*scrollBar: true
XTerm*VT100.titeInhibit: true
XTerm*VT100.colorMode: on
XTerm*VT100.dynamicColors: on
! Uncomment this to use color for underline attribute
XTerm*VT100.colorULMode: on
XTerm*VT100.underLine: off
! Uncomment this to use color for the bold attribute
XTerm*VT100.colorBDMode: on
XTerm*VT100.color0: black
XTerm*VT100.color1: red3
XTerm*VT100.color2: green3
XTerm*VT100.color3: yellow3
XTerm*VT100.color4: blue3
XTerm*VT100.color5: magenta3
XTerm*VT100.color6: cyan3
XTerm*VT100.color7: gray90
XTerm*VT100.color8: gray30
XTerm*VT100.color9: red
XTerm*VT100.color10: green
XTerm*VT100.color11: yellow
XTerm*VT100.color12: blue
XTerm*VT100.color13: magenta
XTerm*VT100.color14: cyan
XTerm*VT100.color15: white
XTerm*VT100.colorUL: yellow
XTerm*VT100.colorBD: white
XTerm*VT100.cursorColor: lime green
XTerm comes with two copies of each resource file, one with color only
(XTerm-col.ad, which is installed as XTerm-color), and the regular one
(XTerm.ad, installed as XTerm). To use the XTerm-color file in
conjunction with a separate XTerm app-defaults file which does not
contain color, add the following line to your .Xdefaults file:
*customization: -color
Since 1997, the resource files grew in size and number. Besides XTerm
and XTerm-color, there are also resource files for xterm using
different class values, together with the -color flavors of these.
Because the -color flavors differ only by an #include statement, the
makefile generates these from XTerm-col.ad. Here are the others:
Program Resource
xterm XTerm
uxterm UXTerm
koi8rxterm KOI8RXTerm
Besides just adding files, I continued testing more resource
combinations. Originally (in the 1990s for instance), developers could
reasonably expect their users to configure resources for themselves,
rather than use a single prepackaged flavor. That was a while ago.
After 2000, I developed nicer resource files. Rather than modify the
installed app-defaults file, I use this feature from X:
Directories named by the environment variable XUSERFILESEARCHPATH or
the environment variable XAPPLRESDIR (which names a single directory
and should end with a ‘/’ on POSIX systems), plus directories in a
standard place (usually under /usr/share/X11/, but this can be
overridden with the XFILESEARCHPATH environment variable) are
searched for for application-specific resources. For example,
application default resources are usually kept in
/usr/share/X11/app-defaults/. See the X Toolkit Intrinsics – C
Language Interface manual for details.
That is, if you set the XAPPLRESDIR environment variable to point to a
directory, you can put application resource files there, and X will
find those before the system app-defaults files. That allows more
flexibility and better control over the various applications than
putting everything into a single .Xdefaults file.
On the opposite extreme, some people advise using xrdb. Not everyone.
Back around 1990 I had an informative conversation with one of the
developers at the Software Productivity Consortium. He was a member of
a team developing a set of X widgets. The gist of our conversation was
that
* using xrdb prevented you from changing things dynamically.
* it was like using a hammer (nailing things down to prevent them
from being different).
* when the only tool you know how to use is a hammer, all of the
problems look like nails.
* a good developer knows how to use more than one tool.
What is this warning message?
xterm: Error 11, errno 22: permission denied
Actually, any message like this denotes a failure which requires
studying the xterm source to determine the exact problem.
You have either found a bug in xterm, or there is something
wrong with your computer's configuration, e.g., not enough
pty's, incorrect permissions, etc.
The first number is an internal code (defined in error.h in
xterm's source), and the second is the system error number
(defined in /usr/include/sys/errno.h). The system error number
is easier to lookup, but the internal error code tells you where
to look in the source.
input method doesn't support my preedit type
Ignore this if you do not know what input method is. Input
methods are used to enter composite characters (e.g., umlauts,
other types of punctuated characters, East Asian characters,
etc). Your computer's libraries support this, but are missing
configuration tables, and xterm is warning you.
If the message bothers you (e.g., if you aren't starting xterm
from a window manager menu), you can suppress it by setting a
resource:
XTerm*openIm:false
Warning: Actions not found: ignore, "xxx"
The action "xxx" (for example "scroll-back") is specified in a
resource file whose translations match widgets that do not
support them. For example, this
XTerm*translations: #override\n\
<Leave>, ~Ctrl ~Meta <Btn2Up>: ignore()\n\
~Shift <Key>KP_8: scroll-back(1,line)\n\
~Shift <Key>KP_2: scroll-forw(1,line)\n\
Shift <Key>KP_8: scroll-back(1,halfpage)\n\
Shift <Key>KP_2: scroll-forw(1,halfpage)
will produce warnings such as
Warning: Actions not found: ignore, scroll-back, scroll-forw
Warning: Actions not found: ignore, scroll-back, scroll-forw
Warning: Actions not found: ignore, scroll-back, scroll-forw
This is a correct form, assigning the actions to the "VT100"
widget.
XTerm*VT100.translations: #override\n\
<Leave>, ~Ctrl ~Meta <Btn2Up>: ignore()\n\
~Shift <Key>KP_8: scroll-back(1,line)\n\
~Shift <Key>KP_2: scroll-forw(1,line)\n\
Shift <Key>KP_8: scroll-back(1,halfpage)\n\
Shift <Key>KP_2: scroll-forw(1,halfpage)
Warning: Cannot allocate colormap entry for "xxx"
This comes from the X library. Modern xterm uses the default
color map. What this means is that if your X server has
insufficient space to store color information for more than one
color map, other applications which could use other color maps
may conflict with xterm. In practice, that is 256 unique colors
on the screen at a time—not enough for a fancy background or an
application such as Netscape.
During resource initialization, xterm attempts to allocate an
entry from the color map for each color which it might use. If
there are not enough free slots in the color map, you will see a
"Cannot allocate" message for each color that xterm failed to
allocate. Those colors will be rendered in the foreground color,
making full-screen color applications such as dialog unreadable.
This problem is alleviated with patch 129, which modified xterm
to delay the most color allocation until the colors are first
needed. If a color is never needed (xterm allocates 20 colors in
this manner), that reduces the number of slots in the color map
that are needed. Even with this improvement, xterm must still
allocate 4 colors during initialization to determine how to
display the cursor. If none of those colors can be allocated,
xterm reverts to monochrome.
Known Bugs in XTerm and Look–alikes
These are the known bugs (or limitations) in modern xterm. They are
also present in the other versions based on the X Consortium sources
(color_xterm, ansi_xterm, kterm).
Note that of the emulators that support color, some do not support bce
(back color erase). The bce capability is also called the "new color
model", though it has been implemented in the IBM PC for quite a while.
Technically, not implementing bce (or allowing the choice between it
and its complement) is not a bug, since few hardware terminals (with
good reason) implemented this feature.
* cut/paste does not select tabs; instead spaces are selected. This
is because the selection works from the array of displayed
characters, on which tab/space conversion has already been
performed.
* does not implement the autorepeat feature of VTxxx terminals.
X11R6.3 XTerm
The X Consortium version of xterm (and versions based on it) has
additional bugs not in modern xterm:
* the program must be run with fixed (nonproportional) fonts.
* the home and end keys do not generate usable escape sequences, due
to an indexing error. (Note that it is possible to work around this
using the VT100 translations resource, but usually this is not
done).
* the Main Options menu is improperly constructed, due to incorrect
indices after removing the logging toggle. This makes the list of
signals off by one.
* very large screens (e.g., by using nil2 for a font) cause core
dumps because the program uses a fixed array (200 lines) for
adjusting pointers.
* certain types of key translations cause a core dump because the
program does not check the event class before attempting to use
events.
(These bugs are also present in the X11R5 version).
Update 2004/04/08:
Complicating this discussion is the "X.Org" xterm (from 2004). That is
the XFree86 xterm from XFree86 CVS with all visible "xfree86" strings
changed to "X.Org" or "xorg", depending on the use. For example the
"xterm-xfree86" terminfo entry becomes "xterm-xorg". The change history
for the related CVS for X.Org shows this. Similarly, the release notes
for X11R6.7 included my notes for XFree86 4.4.
As of 2009, it was apparent that "X.Org" xterm had died a natural
death, since none of the people who created it had any likelihood of
maintaining it. Instead, X.Org defers to my version of xterm.
Reviewing in 2014, the major vendors have been using modern xterm
(different patch levels) for some time. However, there are
documentation problems with AIX, beyond what is noted here:
* AIX provides a copy of luit, and a corresponding manpage—which
omits the sections on security, bugs and attribution.
* The xterm manpage provided with AIX says this is X11R6 xterm “with
no functional enhancements.” Comparing releases X11R5, X11R6.1,
X11R6.3 against the AIX page, it matches X11R6.1 (December 1995).
That is, it includes the text of the X11R6.1 xterm manpage plus the
control sequences document—again omitting the security, bugs and
attribution sections from each.
The other vendors provide documentation which is more up-to-date.
COLOR_XTERM download
This is based on the X Consortium X11R5 source, with the same bugs.
* implements non-bce color model
* moving the cursor is reported to leave trails of incorrect color
* clearing the screen resets colors (arguably this is a limitation).
Not exactly a bug, but it does not build on Linux with X11R6.3
ANSI_XTERM download
This is based on the X Consortium source, with the same bugs.
* implements non-bce color model
* fails vttest by not rendering reverse-video screen
CXTERM download
CXterm stands for "Chinese Xterm". This is based on the X Consortium
source.
DTTERM
This is distributed with CDE. It implements more of the DEC VT220 than
the X Consortium xterm, and also adds controls to manipulate the window
and icon.
* implements non-bce color model
* fails vttest by clearing its background to solid white rather than
preserving its sense in response to ED.
* under some circumstances, scrolling margins are not recognized. For
instance, running vile which uses scrolling margins, we see text
overwriting the status line.
EMU 1.3 download
This is not based on the X Consortium source. The authors state that it
implements VT220 emulation. It is in need of maintenance, since it
builds with some problems to produce an executable that (on Linux and
SunOS) does not handle the carriage return and newline translations
properly. So I am unable to run vttest on this emulator.
ETERM link
Eterm was based on rxvt, though the appearance differs. The terminal
emulation capabilities appear similar, though I am not able to run the
full suite of tests in vttest with this emulator (the core dump noted
for rxvt, as well as hanging while awaiting response from one or more
control sequences). Oddly, it appears that neither Eterm nor rxvt
implement CPR (cursor position report). Finally, it reserves F1
(function-key) for a popup menu. This applies to versions of Eterm
through 0.9.
GNOME TERMINAL link
Unless specifically mentioned, GNOME Terminal and VTE's issues
generally accumulate, with occasional veering off with skin-deep
"rewrites". Each sighting provides a new episode.
Starting in 1999 —
GNOME Terminal is developed separately from both xterm and rxvt, and
was originally based on the zvt (zterm) widget. Like kvt), it appears
to have been developed imitating other terminal emulators (Linux
console and xterm) rather than strictly emulating a VT102. The
documentation is fragmentary (with a comment suggesting that the author
does not know where to find relevant information), and the program
fares badly with vttest. Beginning with late 1999, reports indicate
that it does not properly parse ANSI control sequences: the vim editor
is using xterm's vt220-style "Send Device Attributes" (Secondary DA)
control sequence to obtain the terminal emulator's version. That is, it
sends
\E[>c
expecting a response such as
\E[>0;138;0c
for vt100. The bug report indicates that the "c" sent by vim is echoed
rather than interpreted by the emulator.
But it suffices for vi.
Moving on to 2001 —
A more recent GNOME Terminal uses the VTE widget. I observed version
1.4.0.4 in late 2001, which mentioned it in the credits (although VTE
0.1's ChangeLog mentions no date before February 2002). It does not
implement a complete vt102: it was missing several features which can
be demonstrated in vttest). Most of the bugs in the Device Attributes
responses remain, but it works a little better with vim. However, there
are problems with the alternate screen that show up with vim. Again,
these can be demonstrated with vttest (menu 11.6.3 in the 20011130
snapshot).
Moving on to 2002 —
Rather than evolving from zvt, VTE is largely a new work. It does
credit zvt in one place. However, its source code uses xterm's source
code as a resource, accounting for odd (often incomplete) chunks.
Reviewing 0.9.0 (September 2002):
* the termcap file. The last comment in the file is copied from
xterm's source. The content of course is generated from ncurses
with a small number of changes.
* the parser src/vte.c —a 14,125 line file. For example, the chunks
related to DEC VT220 keyboard queries and DEC private modes contain
comments copied from xterm's source code.
Jumping to 2010 —
Later versions of VTE incorporate more features (and comments, symbol
names, etc), from xterm's source. In some instances, the copied
features were disabled by Red Hat's package for xterm. Here is a
related bug report, for key bindings.
The documentation for GNOME Terminal asserts:
GNOME Terminal emulates the xterm application developed by the X
Consortium. In turn, the xterm application emulates the DEC VT102
terminal and also supports the DEC VT220 escape sequences. An escape
sequence is a series of characters that starts with the Esc
character. GNOME Terminal accepts all of the escape sequences that
the VT102 and VT220 terminals use for functions such as to position
the cursor and to clear the screen.
That sounds fine, except that it is both inaccurate and misleading:
inaccurate
combining the "X Consortium" and "DEC VT220", for example, since
that was done after the demise of said organization.
It emulates a subset of VT100, lacks support for most of the
VT220 control sequences (including some used for positioning the
cursor) that are not recognized by a VT100.
Even in the subset which it emulates, GNOME Terminal has bugs.
Many of these are easy to demonstrate with vttest.
misleading
as noted in Xterm Control Sequences, xterm (mostly after "X
Consortium") supports control sequences which are not
VT100/VT220. GNOME Terminal implements many of these, but not
all.
Perhaps that was unintentional – GNOME developers did not appear to
document what their program does outside of that remark. However, an
inspection of the changelog for libvte (VTE) does show that most of the
borrowing from xterm is cited in an oblique manner – not once
mentioning XFree86 for example, leaving the impression (as indicated by
"X Consortium") that all of the work on xterm was done before
development of GNOME Terminal commenced.
Most of this observation was documented between 2000 and 2007. Other
than maintenance, development of GNOME Terminal appeared to have paused
in 2005. As of 2009, its maintainer was (of the development team), the
least knowledgeable about terminal emulation. So there was no progress
on the large number of bug reports related to xterm-compatibility.
Revisiting in 2018 —
Regarding documentation, the situation was not as good as reported
earlier. The problematic documentation was not even part of the
"official" GNOME Terminal, but was an add-on by a Debian developer,
adapted from GNOME Terminal's online help. The developer's relationship
was mentioned in a Debian bug report:
#127622: ncurses-term: terminfo entry for gnome-terminal swaps
Backspace/Delete:
>> "TD" == Thomas Dickey <dickey@herndon4.his.com> writes:
> On Sun, Jan 06, 2002 at 06:13:30PM +0100, Christian Marillat wrote:
[...]
>> The upstream author should consider ours Debian changes has official
>> changes ?
> sure - get gnome-terminal's author to make the changes. (I generally
> don't add customizations to ncurses' terminfo unless I see them incorporated
> intact by more than one other source).
Sorry to say that, but upstream don't care about my patches. I've
forwarded patches since one year, and these patches has never been
included by upstream. Upstream sayd "commited", but I never seen any
changes.
Christian
The manual page provided as an attachment to GNOME #311565 identifies
the author. However, four years later there is still no manpage for
GNOME Terminal. GNOME #701691 mentions this in conjunction with GNOME
Terminal's incompatible behavior versus other terminals for the “-e”
option:
Christian Persch 2013-06-06 11:10:43 UTC
This works as designed. Note that both -x and -e are deprecated; the only suppor
ted way to pass the arguments is after -- like this:
$ gnome-terminal -- emacs file
and
Christian Persch 2013-06-06 16:02:54 UTC
There are no docs for the gnome-terminal command line options.
Admittedly, GNOME Terminal has some documentation, in its online help
pages. As mentioned, the misleading comments about X Consortium came
from that material, which remained for more than ten years before being
revised early in 2013. Here are a few links for that process:
* help: update introduction.page (2013-01-10)
* help: review (2013-01-09)
* help: modified help in accordance with last review (2013-01-09)
* help: write instroduction.page (2013-01-08)
* help: start rewrite in Mallard (2013-01-08)
The document editors removed this statement
Run any application that is designed to run on VT102, VT220, and
xterm terminals
as well as the extended comment about the X Consortium, and replaced it
with a less specific statement.
Terminal is a terminal emulator application for accessing a UNIX
shell environment which can be used to run programs available on
your system.
Terminal supports escape sequences that control cursor position and
colors.
The assertion about GNOME-Terminal's support for “any” persisted in its
package description in Debian as of 2018:
* Access a UNIX shell in the GNOME environment.
* Run any application that is designed to run on VT102, VT220, and
xterm terminals.
Whether the revised manual is improved or even helpful is debatable.
For instance, it tells the reader how to turn the scrollbar on and off
(using a dialog, of course). But for command-line options, it can print
only about 45 lines of option names and short (less than 10 words)
descriptions for each if one types
gnome-terminal --help-all
Other programs do the equivalent. In a quick check using Debian 8:
* 85 lines for konsole
* 120 lines for xterm patch #331
* 122 lines for mlterm
* 140 lines for urxvt
Bug #311565 was (writing in 2018) more than four years ago, but still
there is no manual page, for either the command-line options or the
control sequences which it supports.
Notes on VTE
VTE is used by developers who provide a facade (also referred to as a
“skin”) for simple desktop-oriented terminal emulation. This page gives
a number of examples with sizes for the skins. The actual program size
is far larger in each case, making the size of the skin irrelevant.
For more than ten years, VTE's README file asserted
VTE supports Unicode and character set conversion, as well as
emulating any terminal known to the system's terminfo database.
The latter part of that ("emulating any terminal") was incorrect. It
did have the ability to work with the standard function-key definitions
which can be defined in a terminfo description. That feature was
discarded in 2014.
Notes from 2010 —
Some of the function-key logic was adapted from xterm; generally
refactoring the xterm source-code to make it appear different. In
places however (naming conventions and comments), there was some
verbatim copying. The same observation can be made of "character set
conversion". None of that is reflected in VTE's git-log.
As an aside, the credits in GNOME Terminal's "About" box also are
inaccurate. For several years (according to its change-log), most of
the work on VTE (the principal part of the program) was done by Nalin
Dahyabhai.
xterm on the other hand, can be told with the tcapFunctionKeys resource
setting to use a more complete subset, based on the ncurses extended
terminal descriptions. However, terminal descriptions describe only one
particular configuration of a terminal. Even xterm's terminfo/termcap
descriptions do not cover the (literally) thousands of keyboard
combinations which are available via its resource settings.
Outside of function-keys, VTE provided no ability to emulate “any
terminal”. A casual glance at its source code revealed the following:
* no support for VT220-style protected areas.
* inconsistent support for modifier keys (the subject of several bug
reports misdirected toward ncurses).
* only a subset of the standard terminfo/termcap properties is used
(5/36 booleans, 3/33 numbers, 125/242 strings other than
function-keys).
* a pervasive assumption that the terminal is something like xterm,
e.g., to provide hardcoded behavior where termcap might describe
something different.
* it uses termcap to retrieve data, rather than providing a choice
between terminfo/termcap, opening up the problem of using an
obsolete database.
* using termcap also means that it has no guidance for following
features which are absent or have limited-functionality compared to
terminfo, such as setting video attributes, colors, etc.
For instance, VTE cannot emulate dtterm, because of differences in
color behavior. In fact, VTE does not use any of the termcap data to
support its interpretation of color control sequences.
After 2014 —
Until 2014, VTE used a termcap file, with its own reader, presumably
under the impression that could be used to describe “any terminal”
(although it was fairly well known that terminals could support escape
sequences not found in any terminal description). As a separate file,
the termcap was a nuisance, whether it was bundled with VTE (and
inaccessible to users) or not. The developers tried it both ways.
One recurring problem was that VTE's termcap did not match xterm's
function-keys. Even when VTE's developers modified the termcap to match
as well as the termcap could, the match was still incomplete. None of
the modified keys were correct, since none of those are described by
termcap. That meant that a control modifier with a cursor-key or
function key was likely to be misread by programs running in VTE.
Finally in 2014, the VTE developers decided to change it. First, one
decided to adapt a chunk of source-code from ncurses, perhaps thinking
that was the way to get a better reader. That did not work well, and
finally they discarded the whole feature, hardcoding the behavior to
match xterm's default configuration.
Here are bug reports which give the story:
* #600659 – Home/End generate wrong control sequences.
Escape sequences of the "default" kbd mode should be okay now.
Removal of non-default kbd modes is continued in bug 730137.
* #169295 – builtin termcap parser not needed.
all: Use terminfo instead of termcap
* #730137 – Drop (or fix) nondefault fkey modes.
Since addressing bug 600659, VTE's default mode pretty accurately
matches XTerm. VT220 is okay-ish, Legacy is so-so, HP and Sun are
quite broken.
* #728900 – use terminfo instead of termcap.
Do we want to rely in term{cap,info} *at all*? So far vte has used
hardwired sequences most of the time. Even if we clean up
everything and drop all fkey modes except the default (request: bug
600659 comment 73) we'd need to keep hardwired sequences for
numerous reasons. E.g. Home/End should generate ^[[H/^[[F which are
not present in terminfo. Application cursor keys and application
keypad mode alter some sequences, with AFAICT no terminfo support
whatsoever. F1..F4 completely change their sequences when a
modifier is pressed, again probably no support for it in terminfo.
Terminfo is just able to encode the complexity (app keypad mode,
app cursor mode, modifiers, numlock) we need. Wouldn't life be much
simpler with just hardwired xterm-compatible sequences? (With
probably a way to override them from config file or dconf for
experts.)
As a minor improvement, those changes removed some of the code whose
origin was cut/paste from xterm. But that does not mean that the VTE
developers stopped that practice. For instance, a change in late 2017
here reminded me to check what VTE does when saving/restoring the
cursor position. It turns out that it does something similar, because
(see #731205 and #741193) the developer studied xterm's source-code and
imitated it (see source changes and followup fixes). There's a quirk in
the resulting program (it pays attention to send/receive and insert
modes, which are unrelated, while also missing the handling of wrap
state), but if the developer had read the documentation (DEC's
manuals), that detail would be missing. In reviewing the documentation,
I noticed a different aspect which might be used to improve xterm, and
ultimately appear in VTE (or perhaps not, since it is in an area poorly
supported by VTE, i.e., the bug which was reported).
VTE developers do more than copy from xterm, of course. There are other
programs (such as Konsole and Terminal.app) which get similar
treatment. Because they tend to copy from others rather than doing
their own solutions, they have not acquired the experience to see why
features were added or modified (or removed), just that it is there.
For instance:
* In a recent rewrite (early 2018), they introduced a skeleton of
code from Paul Williams' sample parser. However, that is only a
skeleton. For the flesh – the usual approach (see above).
Two thirds of the functions listed in the skeleton are no-ops (not
implemented). Some of those listed as implemented do not work (see
vttest screenshot).
Oddly enough, the developers decided to make the program claim that
it is a VT525, though the skeleton demonstrates that it lacks
almost all of features provided by the corresponding hardware
terminal. In October 2018, the listing shows mostly a subset of
VT100, with some (longstanding) features adapted from xterm, and a
few inspired by ECMA-48.
* The latter requires some comment: xterm's control-sequences
document has mentioned ISO-6429 and ECMA-48 since its earliest
version. VTE's developers used that as a reference (see bug
reports) along with xterm's source-code rather than ECMA-48 or
DEC's manuals until around the end of 2016.
* They did (eventually) read documentation referred to by xterm's
documentation. But that took a while, and they began copying from
those sources before understanding the tradeoffs in those. Late in
2016, they started copying features mentioned in ECMA-48. The
motivation for that appears to be (unsurprisingly) copying from yet
another source, e.g., kitty (yet another copyist: see alacritty,
but also see this).
* Introducing those ECMA-48 features caused additional failures for
VTE versus vttest, which the VTE developers solved by making a copy
of vttest, to “fix” the bug. The problematic feature dealt with
clearing tab-stops (selection 2).
ECMA-48 specifies the active line in selection 2. For an
explanation of the term, see ECMA-48 section 6.1.5 Relationship
between active data position and active presentation position. This
is distinct from the feature which DEC's terminals supported.
The VT520 manual is explicit in this case (only selections 0 and 3
are supported). Per Lindberg's 1985 test demonstrated that the
unsupported selection 2 was ignored in a VT100.
* The VT520 did not support the other selection (2) because that
would have been used to support bi-directional text. There is no
point in having two differently-worded descriptions of the same
identical feature.
At the time the VTE developers copied the feature, they had not
begun to develop support bi-directional text (see for example
#321490 (vtebidi) and #767529 (vteemoji).
At this writing (two years later), the developers are talking about
working on that. The tab-clear operation is still identical in VTE
for both selections 2 and 3, and does not implement any of the
features from ECMA-48 not in a DEC terminal.
Other problems with VTE —
These are a few of the interesting bugs found in VTE (or GNOME
Terminal) during 2017:
* system crash due to running out of memory
while running ncurses sample programs dots and picsmap.
* failure to open a remote connection, noticed
while gathering data for a discussion of scrolling performance.
Other uses of VTE —
Because of GNOME Terminal's reputation for excessive code bloat,
developers of every other program based on VTE advertise their version
as reduced memory usage, faster startup, etc. Here are a few of the
available ones:
* osso-xterm link
Its home page refers to "at least two versions". I recall seeing an
older version which was apparently not based on VTE. There did not
appear to be any relevant page (as of 2009) for that version.
* roxterm link
* XFCE Terminal link
MULTI GNOME TERMINAL (MGT) link
Of particular note, MGT 1.4.0 announcement claims that it works
properly for all of vttest)'s tests. On the positive side, it does do
VT52 emulation, but (reading the source code did not help) it
apparently does not really do VT220 from vttest's perspective.
HANTERM download
HanTerm stands for "Hangul term" (Korean). This is based on the XFree86
source.
KONSOLE link
More than just a rewrite of kvt into C++. But there are several
incompatibilities between konsole (noted with version 1.0.2 in late
2001) and xterm:
* none of the selections of keyboard mappings match the actual
behavior of xterm (a few come close, but do so by matching the
terminfo descriptions rather than the programs). In particular, the
application keypad does not send vt100-style escapes.
* vttest) demonstrates that konsole does not properly ignore escape
sequences to switch character sets that it does not support. Also,
the developers of konsole did use an old version of vttest, but
that was to add a bogus Device Attributes response (claimed to be
for "vt220", but not corresponding to any that DEC produced). They
do not use the newer version of vttest (which was available more
than a year before development of konsole began).
* konsole implements several features from XFree86 xterm, but some
are done incorrectly. In particular, the private setmode 1049 does
not save and restore the cursor, causing the cursor to be in
unexpected locations after exiting a fullscreen application such as
vi.
The problems with setmode 1049 were fixed after some time; other issues
linger on.
Like GNOME Terminal, konsole's documentation is incomplete and
inaccurate. This gem from its handbook illustrates the problem:
After a decade, Konsole is the first rewrite from the ground up.
While xterm has definitely been hacked to death (its README begins
with the words Abandon All Hope, Ye Who Enter Here), Konsole offers
a fresh start using contemporary technologies and understanding of
X.
The problem:
* the remark was apparently written in 1997. It was inaccurate at
that time, since it disregards the earlier xvt/rxvt applications.
Limiting it only to a plain statement that konsole was a rewrite of
kvt would have been more accurate. Lacking that context, we find
nonfactual articles such as this on the net.
* for those lacking a proper education, the README was apparently
intended to be a humorous reference to Dante's Inferno.
* reading konsole's source code and considering "hacked to death" can
provide some occasion for humor. Enjoy.
KTERM download
KTerm stands for "Kanji term" (Japanese). This is based on the X
Consortium source, with the same bugs (though the list of original
authors has been removed; the modifications that comprise kterm is
relatively small).
* implements non-bce color model
* implements status line, but uses non-DEC escape sequences for this.
There is a variation of xvt (ancestor of rxvt) originally known as kvt
bundled with KDE which may be referred to as "kterm", but I do not find
it interesting, other than to comment that it was a poor choice of
name.
MLTERM
Mlterm is not based on xterm or rxvt source, though it implements many
of their features. It does fairly well with vttest, except for some odd
misbehavior in operations that save/restore the cursor position.
MTERM
There are a few variants of this: the xterm bundled with some Motif
clients is more common. More interesting, however is one (not Motif),
attributed to "Der Mouse".
(mouse@Lightning.McRCIM.McGill.EDU) Available:
larry.mcrcim.mcgill.edu (132.206.1.1) in
/X/mterm.src/mterm.ball-o-wax.
I saw only an incomplete version of this while it was advertised in the
mid-90's. It is available by email from <mouse@Rodents.Montreal.QC.CA>.
or via ftp. This is not a patched version of xterm, though it was
apparently written, like rxvt, to emulate vt100's. While it does have
some interesting features (such as blinking characters), overall it
does not do as well with vttest as the more widely known emulators.
MXTERM
There are several variants on this: xterm adapted for Motif libraries.
I have seen none that work properly:
* MXTERM: a motif Xterm with character attributes color rendered I've
noticed this one only recently. It is a reworking of the earlier
patches for color_xterm (credited to Erik Fortune at SGI) and the
Motif widgets (apparently first done by Ivan M. Hajadi at SGI in
1991, but credited in this release to Mahesh Neelakanta, for Motif
1.2.4).
* ANSI Xterm with Motif Scrollbar Usually seen as the
ansi-xterm-R6-motif-sb patch, I used this as the starting point for
changes to my #82 patch of xterm in August 1998.
The original patch changes only the scrollbars to Motif, leaving
the popup menus in Athena widgets. That was not what I wanted. My
motivation for using Motif is not for performance or esthetics, of
course, but to make it simpler to build on hosts that have no
Athena widgets installed.
I set those changes aside, having found (the hard way) that the
Motif library has hardcoded behavior regarding the control
right-mouse button. According to the O'Reilly book on Motif
programming (volume 6), it does a server grab when processing
menus. Making the menus behave just as in the Athena widgets can
cause the X server to hang. (I was able to do this with both
Lesstif and Motif libraries). Given that, I decided to restructure
the menus entirely, making a toolbar which could support at
compile-time either widget set.
* mxterm This is a different reworking of the Motif widget patch,
using a 1993 version (ignoring the more recent 1994 patches noted
above). However, it appears to have the same technical defect that
I noted above.
NXTERM
Distributed with Redhat 5.2, it is a repackaging of
xterm-sb_right-ansi, to use the Xaw3d widget set. This is based on the
X Consortium X11R6 source, with the same bugs.
* implements non-bce color model
* does not implement SGR 39 and SGR 49, all attributes are reset when
changing colors.
* popup menus do not appear to work.
Starting with Redhat 6.0, nxterm is the XFree86 3.3.6 xterm.
Unfortunately Redhat neglected to update their termcap for nxterm to
match the program.
RXVT link
Rxvt's manual page states the following unqualified comment:
rxvt, version 2.6.2, is a colour vt102 terminal emulator intended as
an xterm(1) replacement for users who do not require features such
as Tektronix 4014 emulation and toolkit-style configurability. As a
result, rxvt uses much less swap space -- a significant advantage on
a machine serving many X sessions.
How much is much less? Perhaps not as much as one would think from
reading that. The Tektronix emulation in xterm (which has been optional
since late 1997) accounts for about 25kb of the code.
The toolkit-style configurability glibly referenced is the ability to
redefine keys on the keyboard without recompiling the program, i.e.,
the translations resource. It also is the way mouse events and other
actions are passed to xterm.
The toolkit-style configurability accounts for about 300kb, which does
add up if you happen to be running 50 xterm processes (i.e., about
10Mb).
This comment was topical in December 2001:
Compared with something like GNOME Terminal, which takes 2-3 times,
or KDE konsole, which takes 15-20 times as much memory to run, xterm
and rxvt memory requirements are indistinguishable to the normal
user.
In June 2010, the numbers had changed somewhat. Here is a table showing
the total application and library sizes needed for each of the terminal
emulators on my development machine. All sizes are in kb (1024 bytes).
program base size total size libraries
aterm 127 10763 45
color_xterm 142 3647 13
Eterm 1 5126 19
fbiterm 6 2424 8
gnome-terminal 292 14587 51
hpterm 146 14386 31
konsole 2 39815 71
kterm 226 4194 17
mlterm 316 6606 27
mrxvt 298 4515 19
multi-aterm 144 2821 7
pterm 405 12817 42
rxvt 2.6.4 108 2725 6
rxvt 2.7.10 152 2829 7
rxvt-unicode 1259 13641 49
terminal.app 211 15274 29
wterm 110 2922 11
xfce4-terminal 148 14059 48
xgterm 953 4602 14
xhpterm 130 2748 6
xiterm 12 3762 16
xterm (everything) 346 5484 24
xterm (minimal) 186 4123 15
xterm-r5 135 4164 11
xterm-r6 140 4169 11
Counting the libraries is appropriate, since some programs such as
xiterm and the VTE-based programs are implemented in libraries.
These comments apply to versions of rxvt through 2.21:
* clearing the screen resets colors
* does not have a delete key
* the implementation of ech (erase characters) does not follow DEC
VT220 (also ISO 6429), causing applications using this function to
misbehave.
A newer version (upgraded to an beta as of 2.6.PRE3, however, since it
no longer dumps core in vttest) is reported to fix the ech bug.
However, it is less VT100-compatible than the earlier versions such as
2.21b because it does not render reverse video (DECSCNM) properly. All
versions do not update the screen frequently enough, making animation
ineffective. See vttest, tests 1 and 2.
One longstanding issue with rxvt impacts use of xterm. While rxvt does
not use the X Toolkit (and corresponding X resource matching), it does
read your .Xdefaults and app-defaults files to extract resource
settings. That in itself would not be a problem. However, since rxvt
also looks for resources in the XTerm class (a parasitic relationship
like setting $TERM to "xterm" based on the presumption that it is a
nuisance to install its configuration files), there have been several
occasions on which xterm's app-defaults files have been modified to
accommodate rxvt's variant usage.
That comment applies mainly to the resource patterns. However, even
when the pattern is reasonably unambiguous, but overbroad, the results
can be conflicting. For example, some versions of rxvt may accept a
font resource which does not match the XLFD pattern. It accepts a
prefix of "xft:". This feature (apparently introduced by konsole) tells
rxvt to interpret the remainder of the string as a TrueType (Xft) font
rather than a bitmap font. xterm uses the faceName resource for these
values.
st link
Rxvt revisited, this program originally depended only on the X11
library. Since then, it has grown a lot, though the project page does
not mention it. As of January 2013, it was in heavy development, and
(according to comments on its developer's list) growing steadily as the
developers implemented useful features adapted from xterm.
For instance, in 2013, the size counting libraries for st 0.3 on my
Debian testing machine was on a par with rxvt (and half that of xterm,
which uses the X Toolkit library). Revisiting it late in 2015, it had
left rxvt behind and was nearly as large as xterm. Here are the sizes
which I found in Fedora 22:
LDD-Size Program
3452986 rxvt
6060960 st
6771039 mrxvt
7785780 xterm
15060195 urxvt
20934874 lxterminal
21089908 lilyterm
21358156 xfce4-terminal
25738679 roxterm
31195794 gnome-terminal
32780414 terminology
87813125 konsole
By the way, the project page quotes the README file from xterm's
sources, omitting my editorial comment at the top noting that the
paraphrase of the opening from Dante's Inferno dated from 1991, and
pointing to this FAQ to provide better context.
XGTERM link
It has some features which are also in color_xterm:(non-bce ANSI color,
colorBD and colorUL resources, cursor warping, etc. The main feature is
its Tektronix graphics emulation, which is the main reason for this
particular program. Neither program has a change-log, so it is not easy
to say which influenced the other.
That is from reading the source code. However testing under Debian,
something is wrong with the resource processing (neither popup menus
nor colors work).
As of March 2022, Debian's xgterm package does not install the terminal
description which the IRAF developer provided. That was just an alias
for xterm-r5, which still needs some work. If the “xgterm” terminal
description is missing, xgterm falls back to “xterm” which is not a
close match. To address this problem, ncurses provides a workable
xgterm terminal description.
XITERM link
This appears to be rxvt 2.20, lightly reformatted, with a few ifdef's
changed.
That is, it was. The name was later appropriated by a different
program, which also uses the name iterm. Like gnome-terminal, iterm
aims to be an xterm-emulator rather than a VT102- or VT220-emulator.
An earlier attempt by the same author (the "CSI-xterm") incorporated in
2002 some of the changes I made for XFree86 xterm via cut and paste
(but does not mention this in its README). The "borrowed" changes
comprised about 10% of the patch provided for X11R6.5.1, summarized
here:
xterm-6.5.1-i18n-0.7.patch.gz
Imakefile | 25 +
RELNOTES-I18N | 104 ++++++
XTerm.ad | 1
button.c | 155 ++++++++-
charproc.c | 979 ++++++++++++++++++++++++++++++++++++++++++++++++++++------
data.c | 6
data.h | 4
error.h | 8
fontutils.c | 78 ++++
fontutils.h | 8
input.c | 11
main.c | 40 +-
main.h | 1
misc.c | 46 ++
ptyx.h | 156 ++++++++-
screen.c | 513 +++++++++++++++++++++++++++---
scrollbar.c | 36 +-
util.c | 218 +++++++++++-
18 files changed, 2183 insertions(+), 206 deletions(-)
This patch was said to be the basis for Solaris 10 xterm, and was
briefly referred to as the Solaris "color xterm". It did not use the
bce color model however, and Sun provided no terminal description for
it.
Back to iterm: the author's README in the patch used the same
terminology as in the later work, demonstrating their relationship:
This is a patch for the xterm of X11 release 6.5.1 to fix its
internationalization defects. This patch enables xterm to handle
whatever the character set encodings and scripts support underlining
operating system supports via the technology called CSI(Code Set
Independence) and XOM(X Output Method). Traditionally, several
X terminal emulators which are hard-wired to specific languages and
encodings were introduced to support local language requirements, such
as kterm, hanterm, cxterm, UTF-8 xterm and so on. This truly
internationalized terminal emulator supersedes the needs of those
multiple locale specific terminalemulators.
The key to understanding the "code set independence" is that the author
intended to treat existing character encodings on an equal basis with
Unicode and UTF-8. Some of that is reflected in the Solaris
International Language Environments Guide, but in explaining how this
is done, the documentation is weak, lacking detail.
Either version of iterm has similar problems running vttest.
How do I build XTerm?
Building a copy of xterm is simple, provided that you have a
development configuration for X11:
* Header files and libraries. If you do not have the header files
(usually under /usr/include/X11) for your system, you are better
off building the libraries yourself. Xterm can be built with either
X11R5 or X11R6 libraries; however X11R6 requires much more data to
be installed before xterm will run. Xterm uses the Xaw library for
popup menus.
* imake and xmkmf. These utilities produce a Makefile from the
Imakefile. They are not essential, but useful, particularly on
systems with unusual configurations.
If you have a working xmkmf script (or correctly configured imake
utility), all you need to do is type
xmkmf
make
I have written a configure script for xterm which can use imake (or
xmkmf) to generate a Makefile from the Makefile.in. Or it can do
without imake entirely. I have restructured xterm to eliminate most
hardcoded #ifdef's, replacing them with definitions that can be derived
with the configuration script. The configure script is more flexible
than xmkmf, since it allows you to enable or disable a variety of
features. Type
configure --help
to get a list of options.
Though I have replaced most hardcoded ifdef's with autoconfigured
values, it will still continue to build properly with the imake
environment.
However, I usually build xterm using the configure script. By default,
it looks for imake and will use it to help with a few places where a
reliable configure check cannot be created. One of these (see Why
doesn't the scrollbar work?) can be a problem.
As with all of my projects, I routinely check for strict compiler
warnings. For gcc, that is done with the "gcc-stricter" script which
you can find here. The X libraries have a longstanding issue had been
ignored (as of mid-2012). To work around this (and get useful
warnings), I applied this patch:
--- Intrinsic.h.orig 2009-08-25 13:22:15.000000000 -0400
+++ Intrinsic.h 2009-12-06 09:48:39.000000000 -0500
@@ -66,7 +66,11 @@
#define XtSpecificationRelease 6
+#ifdef _CONST_X_STRING
+typedef const char *String;
+#else
typedef char *String;
+#endif
/* We do this in order to get "const" declarations to work right. We
* use _XtString instead of String so that C++ applications can
--- Xresource.h.orig 2009-07-19 14:43:21.000000000 -0400
+++ Xresource.h 2009-12-06 10:11:19.000000000 -0500
@@ -338,8 +338,8 @@
} XrmOptionKind;
typedef struct {
- char *option; /* Option abbreviation in argv */
- char *specifier; /* Resource specifier */
+ _Xconst char *option; /* Option abbreviation in argv */
+ _Xconst char *specifier; /* Resource specifier
*/
XrmOptionKind argKind; /* Which style of option it is */
XPointer value; /* Value to provide if XrmoptionNoArg */
} XrmOptionDescRec, *XrmOptionDescList;
I made note of it on the Xorg mailing list, but as you can see, there
was no response.
Finally, I spent the requisitve time to integrate the change—and
complete the process of transforming the X Toolkit documentation from
nroff to docbook/xml.
How do I report bugs?
You should report bugs to me. I also respond to bug reports in a number
of bug-tracking systems, though some are less open to searches than
others. See also:
* reporting/patching procedures.
* analyzing problems with configure scripts
Additional Information
There appears to be no comprehensive source of information on xterm
better than the documentation which comes with the source code
* XTerm change log
+ The XTerm Manual
+ XTerm Control Sequences
+ resize – set TERMCAP and terminal settings to current xterm
window size
+ uxterm – a UTF-8 wrapper for XTerm
+ koi8rxterm – a KOI8-R wrapper for XTerm
+ luit – Locale and ISO 2022 support for Unicode terminals
* Other Sites
* Interesting but misleading
The XTerm Manual
The command-line options, X resources and similar configurable options
of xterm are documented in the manual page.
Here are copies of the file in various forms: html, pdf, ps and text.
Xterm Control Sequences
Control sequences, i.e., programming information are in the ctlseqs.ms
file which I bundle with the program source. (It used to be in the same
directory in the X distribution, but was moved to a different part of
the tree long ago). Note that you must format this file with different
options than a manpage, e.g.,
tbl ctlseqs.ms | nroff -ms >ctlseqs.txt
tbl ctlseqs.ms | groff -ms >ctlseqs.ps
As a PostScript or PDF file, the individual letters of the control
sequences are all boxed, for emphasis, but I find the text file equally
readable.
Here are copies of the file in various forms: html, pdf, ps and text.
resize – set TERMCAP and terminal settings to current xterm window size
resize is useful by itself, but is maintained for historical reasons as
part of xterm. html, pdf, ps and text.
uxterm – a UTF-8 wrapper for xterm
XTerm does not automatically set your locale. It can be told to use
your locale settings. This is a shell script which sets xterm's
resources to use UTF-8 encoding, and use UTF-8 fonts. There is a
similar lxterm script, but it relies upon non-portable applications,
unlike uxterm.
Here are copies of uxterm's documentation: html, pdf, ps and text.
Incidentally, there was a different program named "uxterm" before the
shell script was added to xterm in mid-2000. Roman Czyborra commented
in 1998 that it was based on the original X11 xterm source (very
likely, since "strings" run on the executable shows the xterm actions,
resources and even the Tek4014 support). There are few references to it
to provide details: the first appearance was in 1994, and the last was
Czyborra's page in 1998. For the curious, there is a copy on
ibiblio.org (no Linux executables, no source, however).
koi8rxterm – a KOI8-R wrapper for xterm
As a special case, this wrapper is packaged with xterm to provide
KOI8-R encoding.
Here are copies of koi8rxterm's documentation: html, pdf, ps and text.
luit – Locale and ISO 2022 support for Unicode terminals
luit also is maintained as part of xterm, since its upstream maintainer
is inactive, and the ostensible maintainers have more than once
delivered unusable versions, causing many bug reports to be issued
against xterm.
Other Sites
* I have found Richard Shuford's archive to be invaluable for notes
on the DEC VT220 and related terminals. This was a webpage but was
last seen via ftp. I have a snapshot of the ftp site, here:
+ ftp://invisible-island.net/shuford/
+ http://invisible-mirror.net/archives/shuford/
* Though not available at the time that I was collecting most of my
notes, VT100.net is also a good source of primary information.
* As part of my Git exports work in 2016, I made a repository of the
major X release copies of xterm source. Alan Coopersmith has a more
extensive repository of the X source, which is also useful although
it does not cover the full timespan. In my repository, I combined
the controls-sequences document which was in specs with the
program:
+ xterm was first released in X10R3, with a manual page in the
man directory, and program in the xterm directory.
+ The developers (re)organized the directory tree in X11, moving
some manual pages under the doc tree, others went along with
the source-code, and moving the programs such as xterm under a
clients directory.
+ The control-sequences document was first released in X11R4.
+ When making the repository, I overlooked the X10 manual page.
Git isn't flexible enough to add that later, without
re-creating the repository.
I use RCS as a starting point for creating Git repositories because
it is the simplest way to capture each file's timestamp. Since the
X developers switched source repositories between X10 and X11, and
the RCS identifiers were no longer in sequence, I used a script to
change those identifiers to a form that would not interfere with
checking the sources into RCS.
The dates shown are, of course, for the xterm source-code:
Date Release Mine Alan's
old-xterm Program Specs
2005-12-14 X11R6.9.0 link n/a n/a
2005-01-12 X11R6.8.2 link n/a n/a
2004-08-20 X11R6.8.0 link n/a n/a
2004-04-02 X11R6.7 link n/a n/a
2001-02-09 X11R6.6 link n/a n/a
2000-08-21 X11R6.5.1 link n/a n/a
1998-02-09 X11R6.4 link n/a n/a
1996-12-09 X11R6.3 link n/a n/a
1996-02-02 X11R6.1 link n/a n/a
1995-01-30 X11R6 link link link
1993-11-11 X11R5 link link link
1989-12-23 X11R4 link link link
1988-10-27 X11R3 link link n/a
1988-03-01 X11R2 link link n/a
1987-09-15 X11R1 link n/a n/a
1986-12-25 X10R4 link n/a n/a
1986-05-17 X10R3 link n/a n/a
Interesting but misleading:
* The ncurses FAQ How do I get color with VT100? discusses a widely
cited bit of misinformation.
For instance, this web search gives 3,000 hits in March 2015.
* Also widely cited, Consistent BackSpace and Delete Configuration
gives advice regarding backspace and delete keys which is heavily
biased toward Linux. For instance:
+ the console referred to is the Linux console, which initially
had as a goal VT220 emulation. Linux never came close to
meeting that goal, which was abandoned in the late 1990s when
UTF-8 became more important.
As part of that, Linux's keyboard was (actually modelled on
xterm) said to be VT220, and its coding for the backspace key
sent DEL. In contrast, ncurses' terminal database says kbs for
the vt220 sends ^H (BS).
+ the guideline uses "newer", "right" and "correct" in the part
which describes DEL, versus "dirty" and "break", "broken" in
that addressing BS.
In addition to bias, the technical remedies are unsuitable for
generic advice. In particular, the comments about terminfo, xmodmap
and xterm's translations resource are suitable only for special
cases because the proposed solutions create problems of their own.
The page itself was written in 1997, with only minor fixes since
then. Thus, it does not reflect any of the improvements made to
xterm. Its lack of relevance does not prevent people from citing
it. For instance, this page's accepted answer recommends that
(although neither gives a useful answer to the question). Here are
a few clues:
+ Debian's current package for ncurses uses the --with-xterm-kbs
configure option which I added in 2012. Debian also applies
patches to many of the terminal descriptions, including adding
a patched copy of xterm's terminfo file to ncurses's terminfo
file.
The patched copy is redundant and a source of problems (since
the two overlap, with slightly different goals regarding PC-
and VT220-style keyboards). My intent in adding the configure
option to ncurses was to wean them away from the patch. That
has not happened yet.
+ tmux is (mostly) a terminfo application. However, it does not
use the terminal database's kbs value. Rather (referring to
the source for 1.9a), it uses the termios setting:
/*
* Check for backspace key using termios VERASE - the termin
fo
* kbs entry is extremely unreliable, so cannot be safely
* used. termios should have a better idea.
*/
bspace = tty->tio.c_cc[VERASE];
if (bspace != _POSIX_VDISABLE && key == bspace)
key = KEYC_BSPACE;
At the same time, tmux sets $TERM to "screen", by default.
Debian patches that terminal description, too. Applications
running inside tmux use that terminal description. If instead
tmux translated the backspace key to match the value from
erasechar (for the given $TERM), its clients would receive
consistent information.
Thus, rather than blaming the user (for a "badly configured"
xterm), the actual problem is a design flaw in tmux which
should have been sent to its developers in a bug report.
* One of the PuTTY developers has a list named “all-escapes” which
begins
# This file is hoped to document all the escape sequences supported by
# terminals that are vaguely compliant with ECMA-48 and friends.
It has been an occasional topic for comment:
+ DECterm special escape sequences ? (Fri Dec 29 08:28:11 2006
on comp.os.vms):
Michael Unger <spam.to.unger@spamgourmet.com> wrote:
> On 2006-12-28 06:20, "JF Mezei" wrote:
>> [...]
>>
>> I tried google, and there are so many sites that list one or two espape
>> sequence that it is nearly impossible to find out whether what I am looking
>> for exists or not.
> There are quite a lot of escape sequences documented in
> <http://bjh21.me.uk/all-escapes/all-escapes.txt> ...
...unfortunately, they're just heaped together in one place, without
a cross-reference (which would show that they're from several types
of terminals).
For a clue regarding the depth of this file, note the first line
# $Id: all-escapes.txt,v 1.32 2005/09/14 12:00:06 ben Exp @
and the 1999's pervading the text. It's basically a cut/paste job
from 1999 with a handful of changes past that point. Compare with
ftp://invisible-island.net/ncurses/terminfo.src.gz
or any of the references cited.
+ Why does cating an executable keep changing the title of
PuTTY? (July 14, 2016 on StackOverflow)
PuTTY recognizes many (by no means all) of the escape sequences used for xterm,
Linux console and some less familiar terminals. One of PuTTY's developers
compiled a list of all of the ones that might be of interest, about 650 items.
...
For whatever reason, they disliked the notion of referring directly to the
documentation for Linux and xterm, but used secondary sources.
The comment about secondary sources was prompted by noticing
that although xterm and vttest are mentioned more than a
hundred times within the document, neither is listed in the
header. Also, the references within the document are all from
September 1999 (xterm #116). For DEC terminals as well, this
uses secondary sources (perhaps just as well, since including
all of the sequences listed in DEC's manuals would make the
file much larger). Most of the links listed in the header are
dead anyway.
The file changes infrequently, but has changed within the past
year (in 2020). There is an xhtml version, perhaps inspired by
this old page (also from 1999).
* Noted here, someone pointed out an NCDware document describing its
terminal control sequences.
Disregarding the title Using VT320 Terminal Emulator Escape
Sequences, it described some variant of xterm rather than a DEC
VT320. VT320s for example had no "alternate screen". Nor did it
have a feature for the "curses (1) fix".
The NCD documentation (dated December 12, 1997) does not mention
xterm. A related manual does mention xterm, but only in other
sections. There are other issues with the manual. For example,
aixterm (16-color) control sequences are documented as
"NCD-specific values". NCD did add escape sequences for status line
(kterm did this as well, according to the 6.2.0 sources dated July
1996), as well as VT220 national replacement characters (which I
added early in 1998).
* Terminal Function Key Escape Codes has good intentions, but falls
astray in several respects.
For a different treatment of the same material, see my notes:
Table of function-keys for XTerm and other Terminal Emulators
First off, it (like the the documentation for GNOME Terminal)
misattributes work which I did, crediting the X Consortium:
This brings me to xterm. xterm has a long history, and the function
key definitions have changed over time. The original xterm from the
X Consortium (even before they were absorbed by The Open Group) used
escape codes based on the VT220, but extended to cover the range
from F1 to F48. F1 through F12 generated, respectively, codes ^[[11~
to ^[[15~, ^[[17~ to ^[[21~, ^[[23~, and ^[[24~. Shift-F1 through
Shift-F12 were used for F13 through F24, and generated codes from
^[[11;2~ to ^[[24;2~. Similarly Ctrl-F1 through Ctrl-F12 were used
for F25 through F36 and generated codes ^[[11;5~ to ^[[24;5~, and
Ctrl-Shift-F1 through Ctrl-Shift-F12 were used for F37 through F48
and generated codes ^[[11;6~ to ^[[24;6~. None of the base xterm
$TERM types on my system correspond to this series of escape codes,
though you can still get xterm to exhibit the old behavior by
setting the OldXtermFKeys resource to 'true'.
Not only that, but the comment (and much of the page) is
inaccurate. For instance:
+ The X Consortium went out of business late in 1996 (see press
release from July 1996).
o The first release of X11R6 was done early in 1996 by X
Consortium.
o I've been working on xterm since before that (see
history).
+ The X Consortium xterm only knew about function keys up to
F20.
o X11R5 defined only 20 function keys, and xterm used only
those since May 1991.
X11R6 changes to xterm did not take advantage of
additional keys aside from the Insert and Delete on the
keypad.
o Further changes by The Open Group through X11R6.6 made no
changes to xterm's handling of special keys.
o That came in xterm patch #130 (2000/3/1), starting with
the SCO function-keys feature.
+ The X Consortium xterm didn't know about using Shift to get
F13 through F24.
o I introduced a similar feature (using Control) in patch
#51 (1997/9/15) as the sunKeyboard resource.
I did this to leave Shift for the VT220 UDK (user-defined
keys).
o rxvt used Shift; the key combination was popular.
o Alexander V Lukyanov's changes in patch #121 to update
the terminal descriptions for these keys took that into
account.
+ The X Consortium xterm didn't know about using Control to get
F25 through F36.
o Even with X11R6, the last function key was XK_F35.
o However, since xterm patch #94 (1999/3/27), it accepts
modifiers (shift, control, alt) to extend the actual set
of keys to generate different escape sequences.
+ The escape sequences described all date from 2002 (xterm patch
#167).
o Besides function-keys, there are two other groups of
special keys on the keyboard: cursor and editing-keypad.
o Before then, the "2" and "5" in cursor- and home/end
sequences would be first (before the semicolon).
o By that point, GNOME Terminal and KDE Konsole had copied
the earlier behavior, and failed to follow this change.
o At the time, I preferred the VT220 keyboard (that does
not support modified special keys).
o However, the app-defaults file which I provided with
xterm did not set the sunKeyboard resource to do this.
Packagers routinely altered the recommended
configuration, so this difference was not noticed for a
while.
o In response to a bug report, I switched to the Sun/PC
keyboard, using the xterm-pc-fkeys building blocks in
ncurses' terminfo description for xterm.
+ The X Consortium xterm had incomplete support for VT100
keypad.
o I added a resource sunKeyboard to tell xterm to look at
other keyboards to simulate the keypad.
o To do this, I made F1 through F4 act like the VT100 PF1
through PF4.
o That came in xterm patch #79 (1998/6/28).
o Not everyone liked that, so I added another resource to
allow turning off the change to F1 through F4.
o Actually OldXtermFKeys is the resource class; the actual
resource is oldXtermFKeys.
By the way, although The Open Group made changes, none of those
have been incorporated in this version of xterm. That was
intentional (see discussion). Consequently, the xterm copyright
makes no mention of The Open Group.
Ongoing/future work
* soft (downloadable) fonts
* printer interface
Done, except for the corresponding support in the VT52 emulation.
It would be nice to have a dialog to control this.
* allow alternate libraries for popup-menus and dialogs
My configure script currently provides tests for the variations of
Athena widgets (Xaw3D, neXtaw). I intend to make additional changes
to support Motif scrollbars and menus. Motif requires a different
style of interface for the menus: binding a popup menu to control
right mouse may cause the server to hang. As an intermediate step,
I implemented a toolbar for the Athena widgets. In turn, that works
well enough except with XFree86 4.x: the Xaw library geometry
management is broken. (Other implementations of the Athena widgets
work well enough).
* popup window that shows hex code for content of a character cell
and hexadecimal keyboard entry for all Unicode characters (ISO
14755)
* correct cut&paste of TAB character
Generated by dwww version 1.15 on Thu May 23 11:18:37 CEST 2024.