%PDF-
%PDF-
Mini Shell
Mini Shell
| Direktori : /usr/share/doc/xterm/ |
|
|
|
| Current File : //usr/share/doc/xterm/xterm.faq.html |
<!--
*****************************************************************************
* Copyright 1997-2021,2022 by Thomas E. Dickey *
* All Rights Reserved. *
* *
* Permission to use, copy, modify, and distribute this software and its *
* documentation for any purpose and without fee is hereby granted, provided *
* that the above copyright notice appear in all copies and that both that *
* copyright notice and this permission notice appear in supporting *
* documentation, and that the name of the above listed copyright holder(s) *
* not be used in advertising or publicity pertaining to distribution of the *
* software without specific, written prior permission. *
* *
* THE ABOVE LISTED COPYRIGHT HOLDER(S) DISCLAIM ALL WARRANTIES WITH REGARD *
* TO THIS SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND *
* FITNESS, IN NO EVENT SHALL THE ABOVE LISTED COPYRIGHT HOLDER(S) BE LIABLE *
* FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES *
* WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN *
* ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF *
* OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. *
*****************************************************************************
$XTermId: xterm.faq.html,v 1.419 2022/12/15 00:49:26 tom Exp $
-->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
<html>
<head>
<meta name="generator" content=
"HTML Tidy for HTML5 for Linux version 5.6.0">
<title>XTerm – Frequently Asked Questions (FAQ)</title>
<link rel="author" href="mailto:dickey@invisible-island.net">
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii">
<meta name="keywords" content=
"xterm, terminal, vt220, vt420, 256-colors, UTF-8">
<meta name="description" content=
"xterm is the standard terminal emulator for the X Window System. This page gives some background and pointers to xterm resources.">
<link rel="SHORTCUT ICON" href="/img/icons/xterm.ico" type=
"image/x-icon">
<link rel="stylesheet" href="/css/simplestyle.css" type=
"text/css">
<link rel="stylesheet" href="/css/inline-code.css" type=
"text/css">
<link rel="stylesheet" href="/css/xterm-icons.css" type=
"text/css">
<style type="text/css">
@import "/css/simplenavXX.css" all;
</style>
<meta name="viewport" content=
"width=device-width, initial-scale=1">
</head>
<body>
<hr>
<p><a href="/">http://invisible-island.net/</a><a href=
"./">xterm/</a><br>
Copyright © 1997-2021,2022 by Thomas E. Dickey</p>
<hr>
<p><a href=
"http://invisible-island.net/xterm/xterm.faq.html">Here</a> is
the latest version of this file.</p>
<h1 class="no-header">XTerm – Frequently Asked Questions
(FAQ)</h1>
<div class="nav">
<ul>
<li class="nav-top"><a href="/xterm/xterm.faq.html">(top)</a></li>
<li><a href="#what_is_it">What is <strong>XTerm</strong>?</a></li>
<li><a href="#who_did_it">Who wrote
<strong>XTerm</strong>?</a></li>
<li><a href="#what_is_vt220">What is a VT220?</a></li>
<li><a href="#what_platforms">What platforms does it run
on?</a></li>
<li><a href="#latest_version">What is the latest version?</a></li>
<li><a href="#other_versions">What versions are
available?</a></li>
<li><a href="#compare_versions">Comparing versions, by
counting controls</a></li>
<li><a href="#how_do_i">How do I ...</a></li>
<li><a href="#frequent_problems">Frequent problems</a></li>
<li><a href="#known_bugs">Known Bugs in
<strong>XTerm</strong> and Look–alikes</a></li>
<li><a href="#building_it">How do I build
<strong>XTerm</strong>?</a></li>
<li><a href="#report_bugs">How do I report bugs?</a></li>
<li><a href="#more_info">Additional Information</a></li>
<li><a href="#future_work">Ongoing/future work</a></li>
</ul>
</div>
<h2 id="what_is_it-id"><a name="what_is_it" id="what_is_it">What
is <strong>XTerm</strong>?</a></h2>
<p>From the manual page:</p>
<blockquote class="code-block">
<p>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.</p>
</blockquote>
<p>That is, xterm (pronounced "<em>eks</em>-term") is a
<em>specific</em> program, not a generic item. It is the standard
X terminal emulator program.</p>
<p>This FAQ presents various useful bits of information for both
the specific program as well as other programs that imitate
it.</p>
<p>As a stylistic convention, the capitalized form is
<em>"XTerm"</em>, which corresponds to the X resource class name.
Similarly, <em>uxterm</em> becomes <em>"UXTerm"</em>.</p>
<h2 id="who_did_it-id"><a name="who_did_it" id="who_did_it">Who
wrote <strong>XTerm</strong>?</a></h2>
<p>I've been working on xterm since early 1996 (see my <a href=
"xterm.log.html">changelog</a> for details).</p>
<p>But the program is much older than that:</p>
<ul>
<li><a href="#prehistory">A Prehistory Perspective</a></li>
<li><a href="#some_digging">Looking for more perspective</a></li>
<li><a href="#my_history">My involvement</a></li>
<li><a href="#forward_history">Focus of this FAQ</a></li>
</ul>
<h3 id="pre_history-id"><a href="#who_did_it" name="prehistory"
id="prehistory">A Prehistory Perspective</a></h3>
<p>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:</p>
<blockquote class="code-block">
<p>Cast of thousands...</p>
<p>To give a bit of history, xterm predates X!</p>
<p>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.</p>
<p>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.</p>
<p>I then did a lot of hacking on it, and merged several
improved versions from others back in.</p>
<p>Notable improvements include the proper ANSI parser, that
Bob McNamara did.</p>
<p>The Tek 4010 support came from a guy at Smithsonian
Astrophysical Observatory whose name slips my mind at the
moment.</p>
<p>Ported to X11 by Loretta Guarino.</p>
<p>Then hacked on at the X Consortium by uncounted people.</p>
</blockquote>
<p>Email from Doug Mink (October 1999) provides more
background:</p>
<blockquote class="code-block">
<p>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.</p>
<p>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.</p>
</blockquote>
<h3><a href="#who_did_it" name="some_digging" id=
"some_digging">Looking for more perspective</a></h3>
<p>VS100 refers to the VAXstation 100, introduced by DEC in 1984
(see <a href=
"http://www.bitsavers.org/pdf/dec/vax/vaxstation100/AA-N660A-TE_VAXstation_100_Users_Guide_Jun84.pdf">
manual</a>).</p>
<p>There is a git repository <a href=
"http://cgit.freedesktop.org/~alanc/xc-historical/log/xc/programs/xterm/">
here</a> which gives some more of xterm's prehistory. But it has
no usable data for X10 (see initial revisions in <a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/log/?ofs=25700">
1985/1986</a>). The X developers did not really start checking in
their code until 1987.</p>
<p>The earliest version of xterm which is available is from
X10R3. According to the xc-historical repository, that was
<a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/commit/?id=49c79082577b5ef39c456c03a047e07d8c702e9f">
February 1, 1986</a> (a change to the <tt>rgb.c</tt> file). Even
that date is suspect because the X10R3 tarball contains xterm
files later than that date:</p>
<blockquote>
<pre class="code-block">
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
</pre>
</blockquote>
<p>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.</p>
<p>A posting by Andreas Motl to <a href=
"https://web.archive.org/web/20151102155441/http://www.netfrag.org/webnews/article.php?id=1064&group=nfo.links.computing">
<em>nfo.links.computing</em></a> in March 2003 recapitulates the
content of a page <a href=
"https://web.archive.org/web/20030618125926/http://www.robotwisdom.com/linux/desktops.html">
<em>Linux desktops (GUIs, widgets, window managers, etc)</em></a>
(Jorn Barger, November 2002). That mentions X10 (e.g., “X
v10”):</p>
<blockquote>
<pre class="code-block">
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]
</pre>
</blockquote>
<p>September 1985 might be accurate for X version 9. However, the
first line of the xterm manual page from X10R3 says</p>
<blockquote>
<pre class="code-block">
.TH XTERM 1 "1 January 1985" "X Version 10"
</pre>
</blockquote>
<p>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.</p>
<p>A comment by Jim Fulton on <a href=
"https://tech.slashdot.org/comments.pl?sid=7262&cid=830314">slashdot
in 2000</a> gives more details on the early versions of X:</p>
<blockquote>
<p class="code-block">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</p>
</blockquote>
<h3 id="my_history-id"><a href="#who_did_it" name="my_history"
id="my_history">My Involvement</a></h3>
<p>My involvement with <strong>xterm</strong> through XFree86
began at the <a href="/xterm/xterm.html#history">end of 1995</a>.
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 <a href=
"/ncurses/ncurses-license.html#patch_961224">release of ncurses
4.0</a>) 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.</p>
<p>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.</p>
<p>Like the other programs that I worked on with others (<a href=
"/vile/vile.html">vile</a>, <a href="/tin/tin.html">tin</a>,
<a href="/lynx/lynx.html">lynx</a>), 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
<a href="/ansification/ansify-xfs-cve.html#xfree86_work">in
November 2000</a>, and stopped mailing patches after <a href=
"xterm.log.html#xterm_149">#149</a>.</p>
<p>Throughout this period, my work on <strong>xterm</strong> 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.</p>
<p>There were exceptions. Christian Weisgerber proposed a package
for FreeBSD ports later in 1999 (<a href=
"https://web.archive.org/web/20130801223050/http://www.mavetju.org/mail/view_message.php?list=freebsd-ports&id=578273">ports/15545:
new port: x11/xterm</a>, followup in <a href=
"http://marc.info/?t=102422536300028&r=l&=2">March
2000</a>). However, that was an exception. None of the Linux
distributions provided a separate package before 2003 (when Mike
Harris created a package of <a href=
"xterm.log.html#xterm_177">patch #177</a> for Red Hat). Again
that is more of an exception than a rule:</p>
<ul>
<li>SuSE's package began October 23, 2004 with <a href=
"xterm.log.html#xterm_196">patch #196</a>.</li>
<li>Mandriva's package began October 22, 2005 with <a href=
"xterm.log.html#xterm_205">patch #205</a>.</li>
<li>The Debian package for xterm began in January 6, 2006 with
<a href="/xterm/xterm.log.html#xterm_204">patch #204</a>.</li>
</ul>
<p>Given that context (sources distributed via XFree86 CVS,
releases via XFree86), the statement made by an Xorg hacker
<a href=
"http://lists.freedesktop.org/archives/xorg/2005-January/005847.html">
early in 2005</a> asserting that “It has not been
maintained by anyone within the XFree86 or X.org trees for many
years” was at best misleading.</p>
<p>After the “<a href=
"xterm.faq.html#xterm-xorg">fork</a>” (sic) of Xorg in
2004, I continued to commit changes for xterm in <a href=
"http://cvsweb.xfree86.org/cvsweb/xc/programs/xterm/">XFree86
CVS</a> until <a href="/xterm/xterm.log.html#xterm_216">patch
#216</a> 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.</p>
<p>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 <a href=
"/personal/git-exports.html">Git snapshots</a> using the RCS
labels which I make in development:</p>
<ul>
<li><a href="/xterm/old-xterm-patches/">Old xterm patches</a>,
from patch #1 through patch #149.</li>
<li><a href=
"https://github.com/ThomasDickey/xterm-snapshots">Git
snapshots</a>, starting from xterm patch #41</li>
</ul>
<h3 id="forward_history-id"><a href="#who_did_it" name=
"forward_history" id="forward_history">Focus of this FAQ</a></h3>
<p>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.</p>
<h2 id="what_is_vt220-id"><a name="what_is_vt220" id=
"what_is_vt220">What is a VT220?</a></h2>
<ul>
<li><a href="#what_vt220">Why a VT220?</a></li>
<li><a href="#whatis_state_table">What is a State Table?</a></li>
<li><a href="#why_not_vt320">Why not emulate VT320?</a></li>
<li><a href="#why_vt420">Why emulate VT420?</a></li>
<li><a href="#why_not_vt520">Why not emulate VT520?</a></li>
</ul>
<h3 id="why_vt220-id"><a name="what_vt220" id="what_vt220">Why a
VT220?</a></h3>
<p>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:</p>
<ul>
<li>VT100s have no function keys. Arguably, PF1-PF4 are
function keys. My keyboard has 12 function keys.</li>
<li>VT100s do not do <a href=
"/ncurses/ncurses.faq.html#vt100_color">color</a>.</li>
</ul>
<p>Initially, I was only interested in making colors workable for
curses programs.</p>
<p>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 <em>National Replacement Character</em>
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).</p>
<p><strong>XTerm</strong> also provides features that are in
neither VT100 nor VT220, which are used by other programs as
"xterm emulation".</p>
<ul>
<li>set (and retrieve) window- and icon-labels using escape
sequences.</li>
<li>interpret mouse clicks as escape sequences that can be read
by a program.</li>
</ul>
<p>By the way, the control string used for setting the titles was
not in a standard format:</p>
<ul>
<li>In X10 (1988), the string was simply terminated by any
nonprinting character.</li>
<li>X11R4 (1989) modified that to ensure that the nonprinting
character is an ASCII BEL (control/G).</li>
<li>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 <code>ESC \</code>.</li>
</ul>
<p>ECMA-48 (the standard) does not describe this particular
control, but prescribes its format (an <a href=
"ctlseqs/ctlseqs.html#h2-Operating-System-Commands">operating
system command</a>). It does not use a
<strong><code>BEL</code></strong>.</p>
<p>I revised that area <a href=
"/xterm/xterm.log.html#xterm_24">starting in 1996</a>,</p>
<ul>
<li>first to use xterm's state table for handling the input,
and then</li>
<li>to accept the standard string terminator as well.</li>
</ul>
<p>In addition to implementing the VT220's <em>National
Replacement Character</em> sets (see vttest <a href=
"/vttest/vttest-nrcs.html">screenshots</a>), I added other
features to emulate the successive models of DEC terminals. The
<a href=
"manpage/xterm.html#VT100-Widget-Resources:decTerminalID"><code>decTerminalID</code></a>
resource (in <a href="xterm.log.html#xterm_29">1996</a>) lets
users select the emulation to use. Because many of my changes
were <em>extensions</em> (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 <a href=
"xterm.log.html#xterm_280">2012</a>, I changed the default from
VT100 to VT420.</p>
<h3 id="whatis_state_table-id"><a name="whatis_state_table" id=
"whatis_state_table">What is a State Table?</a></h3>
<p>That was mentioned regarding the title strings.
<strong>XTerm</strong> 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 <a href=
"/vttest/vttest.html">vttest</a>.</p>
<h3 id="why_not_vt320-id"><a name="why_not_vt320" id=
"why_not_vt320">Why not emulate VT320?</a></h3>
<p>You could do that (by changing <code>decTerminalID</code>, 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).</p>
<p>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 <em>scrolling</em> operations which the VT320
interpreted as <em>panning</em> the visible display in the
terminal's memory. Expect some difference there (if you can find
an application on VMS which used the feature).</p>
<p>The VT320 was popular with developers of commercial terminal
emulators, whose literature referred to it as supporting ANSI
color. It did not do this.</p>
<h3 id="why_vt420-id"><a name="why_vt420" id="why_vt420">Why
emulate VT420?</a></h3>
<p>The VT420 was interesting because it provided two features
that could be useful:</p>
<ul>
<li>rectangles</li>
<li>left/right margins (like the top/bottom scrolling
margins)</li>
</ul>
<p>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 <code>tmux</code>) that could
perform better if the left/right margin feature is available. I
changed the emulation to VT420 in 2012 for this reason.</p>
<p>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.</p>
<h3 id="why_not_vt520-id"><a name="why_not_vt520" id=
"why_not_vt520">Why not emulate VT520?</a></h3>
<p>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.</p>
<p>However:</p>
<ul>
<li>the VT500-series provides additional codepages (like the
VT320). XTerm does that.</li>
<li>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).</li>
</ul>
<p>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.</p>
<h2 id="what_platforms-id"><a name="what_platforms" id=
"what_platforms">What platforms does it run on?</a></h2>
<p><strong>XTerm</strong> 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:</p>
<ul>
<li>AIX 3.2.5, 4.1, 4.3 (cc)</li>
<li>Digital Unix 3.2, 4.0, 5.0 (cc)</li>
<li>FreeBSD 2.2.6 to 6.0 (gcc 2.8)</li>
<li>HP-UX 9.05 to 11.23 (gcc 2.7.2 to 3.4)</li>
<li>IRIX 5.2, 6.2 (cc, gcc 2.7.2, gcc 2.8)</li>
<li>Linux 2.0.0 to 2.6.26 (gcc 2.7.2 to 4.3)</li>
<li>SCO OpenServer 5 (cc, gcc).</li>
<li>Solaris 2.4, 2.5, 2.5.1, 2.6, 7, 8 (cc, gcc 2.7.2)</li>
<li>SunOS 4.1.1, 4.1.3 (gcc 2.7.2)</li>
</ul>
<p>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.</p>
<p>Since 2000, there have been many changes (including new
platforms such as MacOS, NetBSD, OpenBSD, etc., as well as QNX,
Cygwin, and Minix).</p>
<h2 id="latest_version-id"><a name="latest_version" id=
"latest_version">What is the latest version?</a></h2>
<p>The most recent (and well supported) version of xterm is the
one that I maintain:</p>
<ul>
<li><a href="/datafiles/release/xterm.tar.gz">source</a></li>
<li><a href="/archives/xterm/">archives</a></li>
</ul>
<h2 id="other_versions-id"><a name="other_versions" id=
"other_versions">What versions are available?</a></h2>
<p>There are several other versions of xterm, based on xterm's
source. These include</p>
<ul>
<li><a href="#bug_ansi_xterm">ansi_xterm</a></li>
<li><a href="xterm.faq.html#bug_color_xterm">color_xterm</a></li>
<li><a href="#bug_cxterm">cxterm</a> (Chinese)</li>
<li><a href="#bug_hanterm">hanterm</a> (Korean)</li>
<li><a href="#bug_mxterm">mxterm</a></li>
<li><a href="#bug_nxterm">nxterm</a></li>
<li><a href="#bug_kterm">kterm</a> (Japanese)</li>
<li><a href="#bug_xterm_r6">xterm</a> (from X Consortium)</li>
</ul>
<p>There are similar programs not based on xterm's source, which
are compatible to different degrees. These include</p>
<ul>
<li><a href="#bug_dtterm">dtterm</a></li>
<li><a href="#bug_emu">emu</a> (from X Consortium)</li>
<li><a href="#bug_eterm">Eterm</a></li>
<li><a href="#bug_gnometerm">GNOME Terminal</a></li>
<li><a href="#bug_multignome">Multi GNOME Terminal (MGT)</a></li>
<li><a href="#bug_mterm">mterm</a></li>
<li><a href="#bug_konsole">konsole</a></li>
<li><a href="#bug_mlterm">mlterm</a> (Multi Lingual)</li>
<li><a href="#bug_osso_xterm">osso-xterm</a></li>
<li><a href="#bug_roxterm">roxterm</a></li>
<li><a href="#bug_rxvt">rxvt</a></li>
<li><a href="#bug_st">st</a></li>
<li><a href="#bug_xfce_term">xfce-term</a></li>
<li><a href="#bug_xgterm">xgterm</a></li>
<li><a href="#bug_xiterm">xiterm</a></li>
</ul>
<p>Some of these use the <a href="#vte_widget">VTE widget</a>.
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 <a href=
"#bug_dtterm">dtterm</a> and <a href=
"xterm.faq.html#bug_emu">emu</a>.</p>
<p>(I am aware of a few others, such as <strong>xcterm</strong>,
but have not seen a working version of these).</p>
<p>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,</p>
<ul>
<li>PuTTY does this (see its FAQ <a href=
"http://www.chiark.greenend.org.uk/~sgtatham/putty/faq.html#faq-term">
<em>A.5.1 What terminal type does PuTTY use?</em></a>). But its
wrapping behavior is incompatible with xterm (and any vt100
emulator). You can see this in the first menu entry for
<a href="/vttest/vttest.html">vttest</a>.</li>
<li>VTE does this. But consider the list of problems with
<a href=
"https://bugzilla.gnome.org/buglist.cgi?quicksearch=vte">VTE</a>
and with <a href=
"https://bugzilla.gnome.org/buglist.cgi?quicksearch=gnome+terminal">
GNOME Terminal</a>. The attitude of the developers is that by
copying from xterm, they are <em>entitled</em> to do this
whether or not the program actually matches xterm's terminal
description. This is unchanged since the mid-2000s (see Debian
<a href=
"https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368916">#368916</a>
for example).</li>
<li>Konsole does this as well—intentionally as shown in
<a href="https://bugs.kde.org/show_bug.cgi?id=145977"><em>KDE
#145977 – Konsole has a terminfo entry of its own; please
change default $TERM</em></a>. 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
<a href="http://www.linuxjournal.com/article/1136">page about
Gpm</a> from Linux Journal which was more than 12 years
old.</li>
</ul>
<p>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 <a href=
"/ncurses/ncurses.html#download_database">ncurses</a> which
should have been addressed by the respective developers of these
programs. These include</p>
<ul>
<li><a href="/ncurses/terminfo.src.html#tic-_Eterm">Eterm</a></li>
<li><a href="/ncurses/terminfo.src.html#tic-gnome">gnome</a>
(obsolete)</li>
<li><a href=
"/ncurses/terminfo.src.html#tic-konsole">konsole</a></li>
<li><a href="/ncurses/terminfo.src.html#tic-mlterm">mlterm</a></li>
<li><a href="/ncurses/terminfo.src.html#tic-mrxvt">mrxvt</a></li>
<li><a href="/ncurses/terminfo.src.html#tic-putty">putty</a></li>
<li><a href="/ncurses/terminfo.src.html#tic-rxvt">rxvt</a></li>
<li><a href="/ncurses/terminfo.src.html#tic-st">st</a></li>
<li><a href="/ncurses/terminfo.src.html#tic-vte">vte</a>
(preferred)</li>
</ul>
<h2 id="compare_versions-id"><a name="compare_versions" id=
"compare_versions">Comparing versions, by counting controls</a></h2>
<p>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 <a href=
"xterm.faq.html#ctlseqs_ms">ctlseqs.txt</a>. This counts each
control sequence, as well as the variations such as setting bold,
color, inverse video. Then I (laboriously) inspected these
terminal implementations:</p>
<ul>
<li>xterm patch #266 ("xterm-new")</li>
<li>X11R6.3 xterm (xterm-r6)</li>
<li>DEC vt220</li>
<li>DEC vt102</li>
<li>rxvt 2.7.10</li>
<li>rxvt-unicode 9.09 (urxvt)</li>
<li>konsole 2.5.3</li>
<li>VTE 0.25.91 (vte), used in GNOME-Terminal and kindred.</li>
</ul>
<p>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 <em>emulators</em> against
those as well as xterm. There were:</p>
<ul>
<li>498 control sequences listed in the corresponding file for
xterm patch #266.</li>
<li>192 of those are "primary", e.g., disregarding parameters
such as those distinguishing bold from color.</li>
<li>37 of the primary control sequences have secondary
sequences.</li>
</ul>
<p>For each control, there are three possibilities:</p>
<ol>
<li>"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.</li>
<li>"partial" — the terminal implements it, but its
behavior does not match the reference noted above.</li>
<li>"no" — the terminal does not implement the
control.</li>
</ol>
<p>The <a href="ctlseqs/ctlseqs.html">control sequences</a>
document lists a few controls which xterm does not (completely)
implement, e.g.,</p>
<ul>
<li><a href=
"ctlseqs/ctlseqs.html#h4-Functions-using-CSI-_-ordered-by-the-final-character-lparen-s-rparen:CSI-?-Pm-h:Ps-=-8.1E68">
key-repeat</a></li>
<li><a href=
"ctlseqs/ctlseqs.html#h4-Functions-using-CSI-_-ordered-by-the-final-character-lparen-s-rparen:CSI-Ps-q.1CB1">
enabling LEDs</a> other than scroll-lock</li>
</ul>
<p>Those are not implemented in xterm because all X applications
share the same keyboard (see <a href=
"manpage/xterm.html#h2-EMULATIONS">manpage</a>), and <a href=
"https://www.x.org/releases/current/doc/man/man1/xset.1.xhtml">xset</a>
is the proper tool for changing auto-repeat. The <a href=
"https://github.com/ThomasDickey/old-xterm/blob/d448c6d7373c3bc3df4c75e815baa1e645462893/charproc.c#L1048">
X10R4</a> xterm did implement key-repeat, but the feature was
removed in <a href=
"https://github.com/ThomasDickey/old-xterm/blob/6bf1714f13b7811c3e28d186bfc9942d971edd9b/charproc.c#L1048">
X11R1</a>. None of the other terminal emulators implements those
either.</p>
<table border="1" summary=
"Comparing against the control sequences document">
<caption>
Comparing against the control sequences document
</caption>
<colgroup>
<col width="15%">
<col width="15%">
<col width="15%">
<col width="35%">
</colgroup>
<tr>
<th>yes</th>
<th>partial</th>
<th>no</th>
<th>program</th>
</tr>
<tr>
<td>488</td>
<td>4</td>
<td>6</td>
<td>xterm-new</td>
</tr>
<tr>
<td>154</td>
<td>6</td>
<td>338</td>
<td>xterm-r6</td>
</tr>
<tr>
<td>188</td>
<td>5</td>
<td>305</td>
<td>vt220</td>
</tr>
<tr>
<td>104</td>
<td>0</td>
<td>394</td>
<td>vt102</td>
</tr>
<tr>
<td>204</td>
<td>3</td>
<td>291</td>
<td>rxvt</td>
</tr>
<tr>
<td>219</td>
<td>3</td>
<td>276</td>
<td>urxvt</td>
</tr>
<tr>
<td>191</td>
<td>2</td>
<td>305</td>
<td>putty</td>
</tr>
<tr>
<td>170</td>
<td>3</td>
<td>325</td>
<td>konsole</td>
</tr>
<tr>
<td>184</td>
<td>6</td>
<td>308</td>
<td>vte</td>
</tr>
</table>
<p>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.</p>
<p>Aside from that, the various emulators implement much the same
features from xterm. None implements as many as half of xterm's
controls.</p>
<table border="1" summary="Comparing against xterm">
<caption>
Comparing against xterm
</caption>
<colgroup>
<col width="15%">
<col width="15%">
<col width="15%">
<col width="35%">
</colgroup>
<tr>
<th>yes</th>
<th>partial</th>
<th>no</th>
<th>program</th>
</tr>
<tr>
<td>488</td>
<td>0</td>
<td>0</td>
<td>xterm-new</td>
</tr>
<tr>
<td>154</td>
<td>6</td>
<td>328</td>
<td>xterm-r6</td>
</tr>
<tr>
<td>182</td>
<td>2</td>
<td>304</td>
<td>vt220</td>
</tr>
<tr>
<td>98</td>
<td>0</td>
<td>390</td>
<td>vt102</td>
</tr>
<tr>
<td>204</td>
<td>3</td>
<td>281</td>
<td>rxvt</td>
</tr>
<tr>
<td>219</td>
<td>3</td>
<td>266</td>
<td>urxvt</td>
</tr>
<tr>
<td>189</td>
<td>2</td>
<td>297</td>
<td>putty</td>
</tr>
<tr>
<td>170</td>
<td>3</td>
<td>315</td>
<td>konsole</td>
</tr>
<tr>
<td>184</td>
<td>6</td>
<td>298</td>
<td>vte</td>
</tr>
</table>
<p>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.</p>
<table border="1" summary="Comparing against vt220">
<caption>
Comparing against vt220
</caption>
<colgroup>
<col width="15%">
<col width="15%">
<col width="15%">
<col width="35%">
</colgroup>
<tr>
<th>yes</th>
<th>partial</th>
<th>no</th>
<th>program</th>
</tr>
<tr>
<td>182</td>
<td>0</td>
<td>6</td>
<td>xterm-new</td>
</tr>
<tr>
<td>78</td>
<td>6</td>
<td>104</td>
<td>xterm-r6</td>
</tr>
<tr>
<td>188</td>
<td>0</td>
<td>0</td>
<td>vt220</td>
</tr>
<tr>
<td>104</td>
<td>0</td>
<td>84</td>
<td>vt102</td>
</tr>
<tr>
<td>101</td>
<td>3</td>
<td>84</td>
<td>rxvt</td>
</tr>
<tr>
<td>106</td>
<td>3</td>
<td>79</td>
<td>urxvt</td>
</tr>
<tr>
<td>107</td>
<td>2</td>
<td>79</td>
<td>putty</td>
</tr>
<tr>
<td>100</td>
<td>3</td>
<td>85</td>
<td>konsole</td>
</tr>
<tr>
<td>88</td>
<td>6</td>
<td>94</td>
<td>vte</td>
</tr>
</table>
<p>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.</p>
<table border="1" summary="Comparing against vt102">
<caption>
Comparing against vt102
</caption>
<colgroup>
<col width="15%">
<col width="15%">
<col width="15%">
<col width="35%">
</colgroup>
<tr>
<th>yes</th>
<th>partial</th>
<th>no</th>
<th>program</th>
</tr>
<tr>
<td>98</td>
<td>0</td>
<td>6</td>
<td>xterm-new</td>
</tr>
<tr>
<td>70</td>
<td>6</td>
<td>28</td>
<td>xterm-r6</td>
</tr>
<tr>
<td>104</td>
<td>0</td>
<td>0</td>
<td>vt220</td>
</tr>
<tr>
<td>104</td>
<td>0</td>
<td>0</td>
<td>vt102</td>
</tr>
<tr>
<td>79</td>
<td>2</td>
<td>23</td>
<td>rxvt</td>
</tr>
<tr>
<td>81</td>
<td>2</td>
<td>21</td>
<td>urxvt</td>
</tr>
<tr>
<td>86</td>
<td>2</td>
<td>16</td>
<td>putty</td>
</tr>
<tr>
<td>85</td>
<td>3</td>
<td>16</td>
<td>konsole</td>
</tr>
<tr>
<td>60</td>
<td>1</td>
<td>43</td>
<td>vte</td>
</tr>
</table>
<p>I have continued to add features to xterm:</p>
<ul>
<li>as of September 2013, it implemented 546 of 556 documented
controls</li>
<li>as of October 2019, xterm implemented 713 of 723 documented
controls.</li>
</ul>
<p>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
<a href="/vttest/vttest-nrcs.html">vttest NRCS</a> examples).</p>
<p>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.</p>
<h2 id="how_do_i-id"><a name="how_do_i" id="how_do_i">How do I
...</a></h2>
<p>Not really problems, but frequently asked questions (the point
of this, after all):</p>
<ul>
<li><a href="#how2_fsize">How do I change the font size?</a></li>
<li><a href="#how2_print">How do I print the screen?</a></li>
<li><a href="#how2_fkeys">How do I set up function keys?</a></li>
<li><a href="#how2_title">How do I set the title?</a></li>
<li><a href="#how2_blink">How do I make the cursor blink?</a></li>
</ul>
<h3 id="how2_fsize-id"><a name="how2_fsize" id="how2_fsize">How
do I change the font size?</a></h3>
<p><strong>XTerm</strong> 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 <a href=
"/xterm/manpage/xterm.html#MENUS">MENUS</a> section.</p>
<p>X Consortium xterm provides popup menus, by pressing the
control key together with the mouse button. Control right mouse
button pops up the <em>VT FONTS</em> menu, from which you can
select fonts that are specified in xterm's resources. Usually
these are in increasing order of size.</p>
<p>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.</p>
<p><strong>XTerm</strong>'s manpage does not document the syntax
for X resources; it is done in the X documentation. If you are
instead asking about a <a href=
"xterm.faq.html#utf8_fonts">problem displaying a given font</a>,
it may be due to a problem with your resource settings.</p>
<h3 id="how2_print-id"><a name="how2_print" id="how2_print">How
do I print the screen?</a></h3>
<p>That depends on why you want to print it.</p>
<p>If you want a trace of an interactive session, you should use
the <em>script</em> program. It records every character sent to
the screen, recording them in a file <code>typescript</code>.
There are two drawbacks to this approach:</p>
<ul>
<li>Every character is recorded. Even cursor movement, if you
run an editor.</li>
<li>You must start a new shell to capture the
<code>typescript</code> file.</li>
</ul>
<p>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 <a href="#bug_xterm_r6">bug</a> in xterm).
Some people prefer this, because it is convenient: you can start
and stop logging a popup menu entry. However</p>
<ul>
<li>Every character is recorded. Even cursor movement, if you
run an editor.</li>
<li>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).</li>
</ul>
<p>Both <em>script</em> 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).</p>
<p>If you want to print the contents of the screen, modern xterm
implements, as part of the VT100 emulation, an "attached"
printer.</p>
<ul>
<li>The printer is really a pipe command, to which xterm
writes.</li>
<li>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.</li>
<li>If you do not have an application, xterm has a popup menu
entry to print the window.</li>
</ul>
<p>There are limitations and tradeoffs using the "attached"
printer, because it is an emulation:</p>
<ul>
<li>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
<code>printAttributes</code> to get more easily printed
output.</li>
<li>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 <code>printerAutoClose</code> resource
to change xterm's behavior to close the printer pipe whenever
the terminal is told to switch the printer offline.</li>
</ul>
<p>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.</p>
<h3 id="how2_fkeys-id"><a name="how2_fkeys" id="how2_fkeys">How
do I set up function keys?</a></h3>
<p>With modern xterm, this is relatively simple. So I'll answer
that first.</p>
<p>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).</p>
<p>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
<code>sunKeyboard</code>, 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).</p>
<p>The emulation level for modern xterm is set via the resource
<code>decTerminalID</code>, 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.</p>
<p>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:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
xterm <span class=
"ident2">$XTERMFLAGS</span> +rw +sb +ls <span class="ident2">$@</span> -tm <span class="literal">'erase ^? intr ^c'</span> \<br>
-name vt220 -title vt220 -tn xterm-220 <span class="literal">"$@"</span> &<br>
<!--atr2html}}--></p>
</blockquote>
<p>with the corresponding resources:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">translations</span>:<span class=
"literal"> #override \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Home: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">3</span><span class="literal">~") \n \<br>
</span><span class="keyword"><Key></span><span class="literal">End: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">4</span><span class="literal">~") \n</span><br>
<span class="ident2">vt220</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">translations</span>:<span class=
"literal"> #override \n\<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F1: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("OP") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F2: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("OQ") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F3: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("OR") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F4: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("OS") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F5: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">16</span><span class="literal">~") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F6: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">17</span><span class="literal">~") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F7: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">18</span><span class="literal">~") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F8: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">19</span><span class="literal">~") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F9: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">20</span><span class="literal">~") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F10: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">21</span><span class="literal">~") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F11: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">28</span><span class="literal">~") \n \<br>
~Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F12: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">29</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F1: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">23</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F2: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">24</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F3: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">25</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F4: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">26</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F5: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[K~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F6: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">31</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F7: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">31</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F8: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">32</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F9: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">33</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F10: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">34</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F11: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">28</span><span class="literal">~") \n \<br>
Shift </span><span class=
"keyword"><Key></span><span class=
"literal">F12: string(</span><span class=
"number">0x1b</span><span class=
"literal">) string("[</span><span class=
"number">29</span><span class="literal">~") \n \<br>
</span><span class="keyword"><Key></span><span class="literal">Print: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">32</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Cancel: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">33</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Pause: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">34</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Insert: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">2</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Delete: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">3</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Home: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">1</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">End: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">4</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Prior: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">5</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Next: string(</span><span class="number">0x1b</span><span class="literal">) string("[</span><span class="number">6</span><span class="literal">~") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">BackSpace: string(</span><span class="number">0x7f</span><span class="literal">) \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Num_Lock: string(</span><span class="number">0x1b</span><span class="literal">) string("OP") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_Divide: string(</span><span class="number">0x1b</span><span class="literal">) string("Ol") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_Multiply: string(</span><span class="number">0x1b</span><span class="literal">) string("Om") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_Subtract: string(</span><span class="number">0x1b</span><span class="literal">) string("OS") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_Add: string(</span><span class="number">0x1b</span><span class="literal">) string("OM") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_Enter: string(</span><span class="number">0x1b</span><span class="literal">) string("OM") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_Decimal: string(</span><span class="number">0x1b</span><span class="literal">) string("On") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_0: string(</span><span class="number">0x1b</span><span class="literal">) string("Op") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_1: string(</span><span class="number">0x1b</span><span class="literal">) string("Oq") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_2: string(</span><span class="number">0x1b</span><span class="literal">) string("Or") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_3: string(</span><span class="number">0x1b</span><span class="literal">) string("Os") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_4: string(</span><span class="number">0x1b</span><span class="literal">) string("Ot") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_5: string(</span><span class="number">0x1b</span><span class="literal">) string("Ou") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_6: string(</span><span class="number">0x1b</span><span class="literal">) string("Ov") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_7: string(</span><span class="number">0x1b</span><span class="literal">) string("Ow") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_8: string(</span><span class="number">0x1b</span><span class="literal">) string("Ox") \n\<br>
</span><span class="keyword"><Key></span><span class="literal">KP_9: string(</span><span class="number">0x1b</span><span class="literal">) string("Oy") \n</span><br>
<br>
<span class=
"comment">! <Key>Up: string(0x1b) string("[A") \n\<br>
</span> <span class=
"comment">! <Key>Down: string(0x1b) string("[B") \n\<br>
</span> <span class=
"comment">! <Key>Right: string(0x1b) string("[C") \n\<br>
</span> <span class=
"comment">! <Key>Left: string(0x1b) string("[D") \n\<br>
</span> <br>
*<span class="ident2">visualBell</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
*<span class="ident2">saveLines</span>:<span class=
"literal"> </span><span class=
"number">1000</span><br>
*<span class="ident2">cursesemul</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
*<span class="ident2">scrollKey</span>:<span class=
"literal"> </span><span class="keyword">true</span><br>
*<span class="ident2">scrollBar</span>:<span class=
"literal"> </span><span class="keyword">true</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>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).</p>
<p>Here's another one, from Robert Ess
<ress@spd.dsccc.com>:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="comment">#!/bin/sh</span><br>
<br>
<span class=
"comment"># vax</span><br>
<span class=
"comment"># 09-17-96 Bob Ess - initial creation</span><br>
<span class=
"comment"># 09-26-96 Shig Katada - Additional keybindings</span><br>
<span class="comment">#</span><br>
<span class=
"comment"># Script file to incorporate keybindings and command line</span><br>
<span class=
"comment"># options for connecting to a VAX node</span><br>
<br>
<span class="comment"># Usage statement</span><br>
Usage()<span class="keyword2">{</span><br>
<span class=
"keyword">echo</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Usage : vax -options"</span><br>
<span class=
"keyword">echo</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Options: -80 for 80 column terminal"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -132 for 132 column terminal"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -fg colorname"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -bg colorname"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -fn fontname"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -fb bold fontname"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -host [altair] [devel] [leonis] [castor]"</span><br>
<span class=
"keyword">echo</span> <span class="literal">""</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Example: </span><span class=
"keyword2">\</span><span class=
"literal">"vax -80 -fg white -bg black -fn 9x15 -fb 9x15b -host castor</span><span class="keyword2">\</span><span class="literal">""</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Starts a VAX session with an 80 column terminal"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" with a black background, white foreground, a normal"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" font of 9x15 and a bold font of 9x15b, and connects"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" to the node 'castor'"</span><br>
<span class=
"keyword">echo</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" If you need additional help, please call Workstation"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Services at x92396."</span><br>
<span class=
"keyword">echo</span><br>
<span class=
"keyword">exit</span> <span class="number">1</span><br>
<span class="keyword2">}</span><br>
<br>
<span class=
"comment"># Default to a black foreground with a white background.</span><br>
<span class=
"comment"># Use the 9x15 and 9x15bold fonts. Connect to castor by default.</span><br>
<span class="comment">#</span><br>
<span class="ident2">FG</span>=black<br>
<span class="ident2">BG</span>=white<br>
<span class="ident2">HOST</span>=castor<br>
<span class="ident2">FONT</span>=<span class=
"number">9</span>x15<br>
<span class="ident2">BFONT</span>=<span class=
"number">9</span>x15bold<br>
<span class="ident2">COLS</span>=<span class=
"number">80</span><br>
<br>
<span class=
"comment"># Parse the command line arguments</span><br>
<span class="comment">#</span><br>
<span class="keyword">while</span> [ <span class=
"ident2">$#</span> != <span class=
"number">0</span> ];<br>
<span class="keyword">do</span><br>
<span class=
"keyword">case</span> <span class=
"ident2">$1</span> <span class="keyword">in</span><br>
<span class="number">-80</span>) <span class="ident2">COLS</span>=<span class="number">80</span><br>
<span class="ident2">FONT</span>=spc12x24c<br>
<span class="ident2">BFONT</span>=spc12x24b<br>
<span class="keyword">shift</span><br>
;;<br>
<span class="number">-132</span>) <span class="ident2">COLS</span>=<span class="number">132</span><br>
<span class="ident2">FONT</span>=<span class="number">9</span>x15<br>
<span class="ident2">BFONT</span>=<span class="number">9</span>x15b<br>
<span class="keyword">shift</span><br>
;;<br>
-fg) <span class="keyword">shift</span><br>
<span class="ident2">FG</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-bg) <span class="keyword">shift</span><br>
<span class="ident2">BG</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-fn) <span class="keyword">shift</span><br>
<span class="ident2">FONT</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-fb) <span class="keyword">shift</span><br>
<span class="ident2">BFONT</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-host) <span class="keyword">shift</span><br>
<span class="ident2">HOST</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-help) Usage;;<br>
*) Usage;;<br>
<span class=
"keyword">esac</span><br>
<span class="keyword">done</span><br>
<br>
xterm -title <span class=
"literal">"VAX"</span> -sb -sl <span class=
"number">1200</span> -geo <span class=
"ident2">${COLS}</span>x24 -fg <span class=
"ident2">${FG}</span> -bg <span class=
"ident2">${BG}</span> \<br>
-cr red -fn <span class="ident2">${FONT}</span> -fb <span class="ident2">${BFONT}</span> -xrm \<br>
<span class=
"literal">'XTerm*VT100.translations: #override \n\<br>
<Key>Insert: string(\001) \n\<br>
Shift <Key>Up: scroll-back(1,lines) \n\<br>
Shift <Key>Down: scroll-forw(1,lines) \n\<br>
Shift <Key>Right: string(0x1b) string("f") \n\<br>
Shift <Key>Left: string(0x1b) string("b") \n\<br>
Shift <Key>Delete: string(0x1b) string(0x08) \n\<br>
Shift <Key>Tab: string(0x1b) string("*") \n\<br>
<Key>0x1000FF0D: scroll-back(1,page) \n\<br>
<Key>0x1000FF0E: scroll-forw(1,page) \n\<br>
<Key>0x1000FF09: string(\010) \n\<br>
<Key>0x1000FF0A: string(\005) \n\<br>
<Key>BackSpace: string(0xff) \n\<br>
<Key>Select: select-start() \n\<br>
<Key>0x1000FF02: select-end(PRIMARY,CUT_BUFFER0) \n\<br>
Meta <Key>0x1000FF02: select-end(CLIPBOARD) \n\<br>
<Key>0x1000FF04: insert-selection(PRIMARY,CUT_BUFFER0) \n\<br>
Meta <Key>0x1000FF04: insert-selection(CLIPBOARD) \n\<br>
<Key>F1: string(0x1b) string("OP") \n\<br>
<Key>F2: string(0x1b) string("OQ") \n\<br>
<Key>F3: string(0x1b) string("OR") \n\<br>
<Key>F4: string(0x1b) string("OS") \n\<br>
<Key>F5: string(0x1b) string("OA") \n\<br>
<Key>F11: string(0x1b) string("[23~") \n\<br>
<Key>F12: string(0x1b) string("[24~") \n\<br>
<Key>KP_0: string(0x1b) string("Op") \n\<br>
<Key>KP_1: string(0x1b) string("Oq") \n\<br>
<Key>KP_2: string(0x1b) string("Or") \n\<br>
<Key>KP_3: string(0x1b) string("Os") \n\<br>
<Key>KP_4: string(0x1b) string("Ot") \n\<br>
<Key>KP_5: string(0x1b) string("Ou") \n\<br>
<Key>KP_Divide: string(0x1b) string("OP") \n\<br>
<Key>KP_Multiply: string(0x1b) string("[29~") \n\<br>
<Key>KP_Enter: string(0x1b) string("OM") \n\<br>
<Key>KP_Subtract: string(0x1b) string("Om") \n\<br>
<Key>KP_Add: string(0x1b) string("Ol") \n\<br>
<Key>KP_Decimal: string(0x1b) string("On") \n\<br>
<Btn1Down>: select-start() \n\<br>
<Btn1Motion>: select-extend() \n\<br>
<Btn1Up>: select-end(PRIMARY,CUT_BUFFER0) \n\<br>
Button1<Btn2Down>: select-end(CLIPBOARD) \n\<br>
Button1<Btn2Up>: ignore()'</span> \<br>
-e telnet <span class="ident2">$HOST</span> &<br>
<!--atr2html}}--></p>
</blockquote>
<p>Finally (for the moment) is a further modification of Robert
Ess's script by <a href=
"https://web.archive.org/web/20110411233005/http://www-personal.une.edu.au/~oahlefel/vmsterm.htm">
Erik Ahlefeldt</a>, <oahlefel@metz.une.edu.au>. From his
readme file, for vmsterm:</p>
<blockquote>
<p>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.</p>
<p>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.</p>
<p>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.</p>
<dl>
<dt>Function keys.</dt>
<dd>
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.
<p>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.</p>
</dd>
<dt>Xterm functionality.</dt>
<dd>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.</dd>
</dl>
</blockquote>
<p>a summary of the keyboard mapping:</p>
<blockquote>
<pre class="code-block">
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
</pre>
</blockquote>
<p>and the script:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="comment">#!/bin/sh</span><br>
<span class=
"comment"># vmsterm</span><br>
<span class=
"comment"># from an original script by Bob Ess</span><br>
<span class=
"comment"># key translations by Erik Ahlefeldt </span><br>
<span class="comment">#</span><br>
<span class=
"comment"># Script file using Xterm and telnet to connect to a VMS host</span><br>
<span class=
"comment"># and give a decent vt220 emulation.</span><br>
<span class="comment">#</span><br>
<span class="comment"># Usage statement</span><br>
Usage()<strong><em><span class=
"comment">{</span></em></strong><br>
<span class=
"keyword">echo</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Usage : vmsterm -options"</span><br>
<span class=
"keyword">echo</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Options: -80 for 80 column terminal"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -132 for 132 column terminal"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -bg colorname"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -fg colorname"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -fn fontname"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -fb bold fontname"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" -host [crusher.saltmine.com] [earth] [192.168.7.7]"</span> <br>
<span class=
"keyword">echo</span> <span class="literal">""</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Example: </span><strong><em><span class=
"comment">\</span></em></strong><span class=
"literal">"vmsterm -80 -fg white -bg black -fn 9x15 -fb 9x15b -host earth</span><strong><em><span class="comment">\</span></em></strong><span class="literal">""</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Starts a VMS session with an 80 column terminal"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" with a black background, white foreground, a normal"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" font of 9x15 and a bold font of 9x15b, and connects"</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" to the node 'earth'"</span><br>
<span class=
"keyword">echo</span> <span class="literal">""</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Example: </span><strong><em><span class=
"comment">\</span></em></strong><span class=
"literal">"vmsterm -host earth</span><strong><em><span class="comment">\</span></em></strong><span class="literal">""</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Starts a VMS session with default terminal settings "</span><br>
<span class=
"keyword">echo</span> <span class="literal">""</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Example: </span><strong><em><span class=
"comment">\</span></em></strong><span class=
"literal">"vmsterm -help</span><strong><em><span class=
"comment">\</span></em></strong><span class=
"literal">""</span><br>
<span class=
"keyword">echo</span> <span class=
"literal">" Displays vmsterm options "</span><br>
<span class=
"keyword">echo</span><br>
<span class=
"keyword">exit</span> <span class="number">1</span><br>
<strong><em><span class="comment">}</span></em></strong><br>
<br>
<span class=
"comment"># Default to a black foreground with a white background.</span><br>
<span class=
"comment"># Use the 9x15 and 9x15bold fonts. Connect to 192.168.3.3 by default.</span><br>
<span class="comment">#</span><br>
<span class="ident2">FG</span>=black<br>
<span class="ident2">BG</span>=white<br>
<span class="ident2">HOST</span>=192.168.3.3<br>
<span class="ident2">FONT</span>=9x15<br>
<span class="ident2">BFONT</span>=9x15bold<br>
<span class="ident2">COLS</span>=<span class=
"number">80</span><br>
<br>
<span class=
"comment"># Parse the command line arguments</span><br>
<span class="comment">#</span><br>
<span class="keyword">while</span> [ <span class=
"ident2">$#</span> != <span class=
"number">0</span> ];<br>
<span class="keyword">do</span><br>
<span class=
"keyword">case</span> <span class=
"ident2">$1</span> <span class="keyword">in</span><br>
<span class="number">-80</span>) <span class="ident2">COLS</span>=<span class="number">80</span><br>
<span class="ident2">FONT</span>=spc12x24c<br>
<span class="ident2">BFONT</span>=spc12x24b<br>
<span class="keyword">shift</span><br>
;;<br>
<span class="number">-132</span>) <span class="ident2">COLS</span>=<span class="number">132</span><br>
<span class="ident2">FONT</span>=9x15<br>
<span class="ident2">BFONT</span>=9x15b<br>
<span class="keyword">shift</span><br>
;;<br>
-fg) <span class="keyword">shift</span><br>
<span class="ident2">FG</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-bg) <span class="keyword">shift</span><br>
<span class="ident2">BG</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-fn) <span class="keyword">shift</span><br>
<span class="ident2">FONT</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-fb) <span class="keyword">shift</span><br>
<span class="ident2">BFONT</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-host) <span class="keyword">shift</span><br>
<span class="ident2">HOST</span>=<span class="ident2">$1</span><br>
<span class="keyword">shift</span>;;<br>
-help) Usage;;<br>
*) Usage;;<br>
<span class=
"keyword">esac</span><br>
<span class="keyword">done</span><br>
<br>
xterm -title <span class=
"literal">"VMSTERM"</span> -sb -sl <span class=
"number">1000</span> -geo <span class=
"ident2">${COLS}</span>x24 -fg <span class=
"ident2">${FG}</span> -bg <span class=
"ident2">${BG}</span> \<br>
-cr blue -fn <span class="ident2">${FONT}</span> -fb <span class="ident2">${BFONT}</span> -xrm \<br>
<span class=
"literal">"XTerm*vt100.translations: #override </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F1: string(0x1b) string("</span>OP<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F2: string(0x1b) string("</span>OQ<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F3: string(0x1b) string("</span>OR<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F4: string(0x1b) string("</span>OS<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F5: string("</span>Break<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F6: string(0x1b) string("</span>[<span class="number">17</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F7: string(0x1b) string("</span>[<span class="number">18</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F8: string(0x1b) string("</span>[<span class="number">19</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F9: string(0x1b) string("</span>[<span class="number">20</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F10: string(0x1b) string("</span>[<span class="number">21</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F11: string(0x1b) string("</span>[<span class="number">23</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>F12: string(0x1b) string("</span>[<span class="number">24</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F1: string(0x1b) string("</span>[<span class="number">23</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F2: string(0x1b) string("</span>[<span class="number">24</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F3: string(0x1b) string("</span>[<span class="number">25</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F4: string(0x1b) string("</span>[<span class="number">26</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F5: string(0x1b) string("</span>[<span class="number">28</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F6: string(0x1b) string("</span>[<span class="number">29</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F7: string(0x1b) string("</span>[<span class="number">31</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F8: string(0x1b) string("</span>[<span class="number">32</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F9: string(0x1b) string("</span>[<span class="number">33</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F10: string(0x1b) string("</span>[<span class="number">34</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F11: string(0x1b) string("</span>[<span class="number">28</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>F12: string(0x1b) string("</span>[<span class="number">29</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Print: string(0x1b) string("</span>[<span class="number">28</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Cancel: string(0x1b) string("</span>[<span class="number">29</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Pause: string(0x1b) string("</span>Om<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Insert: string(0x1b) string("</span>[<span class="number">2</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Delete: string(0x1b) string("</span>[<span class="number">3</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Home: string(0x1b) string("</span>[<span class="number">1</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>End: string(0x1b) string("</span>[<span class="number">4</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Prior: string(0x1b) string("</span>[<span class="number">5</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Next: string(0x1b) string("</span>[<span class="number">6</span>~<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>BackSpace: string(0x7f) </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Num_Lock: string(0x1b) string("</span>OP<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_Divide: string(0x1b) string("</span>OQ<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_Multiply: string(0x1b) string("</span>OR<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_Subtract: string(0x1b) string("</span>OS<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_Add: string(0x1b) string("</span>Ol<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_Enter: string(0x1b) string("</span>OM<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_Decimal: string(0x1b) string("</span>On<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_0: string(0x1b) string("</span>Op<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_1: string(0x1b) string("</span>Oq<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_2: string(0x1b) string("</span>Or<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_3: string(0x1b) string("</span>Os<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_4: string(0x1b) string("</span>Ot<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_5: string(0x1b) string("</span>Ou<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_6: string(0x1b) string("</span>Ov<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_7: string(0x1b) string("</span>Ow<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_8: string(0x1b) string("</span>Ox<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>KP_9: string(0x1b) string("</span>Oy<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>Up: string(0x1b) string("</span>[A<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>Up: scroll-back(1,lines) </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
~Shift <Key>Down: string(0x1b) string("</span>[B<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
Shift <Key>Down: scroll-forw(1,lines) </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Right: string(0x1b) string("</span>[C<span class="literal">") </span><strong><em><span class="comment">\</span></em></strong><span class="literal">n </span><strong><em><span class="comment">\</span></em></strong><span class="literal"><br>
<Key>Left: string(0x1b) string("</span>[D<span class="literal">")"</span> \<br>
-e telnet <span class="ident2">$HOST</span> <br>
<!--atr2html}}--></p>
</blockquote>
<h3 id="how2_title-id"><a name="how2_title" id="how2_title">How
do I set the title?</a></h3>
<p>The control sequences for doing this are documented in
<a href="#ctlseqs_ms">ctlseqs.ms</a>.</p>
<p>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:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">if</span> [ <span class=
"literal">"</span><span class=
"ident2">$SHELL</span><span class="literal">"</span> = <span class="literal">"/bin/pdksh"</span> -o <span class="literal">"</span><span class="ident2">$SHELL</span><span class="literal">"</span> = <span class="literal">"/bin/ksh"</span> ]; <span class="keyword">then</span><br>
<span class=
"ident2">PS1</span>=<span class=
"literal">"! $ "</span><br>
<span class="keyword">elif</span> [ <span class=
"literal">"</span><span class=
"ident2">$SHELL</span><span class="literal">"</span> = <span class="literal">"/bin/zsh"</span> ]; <span class="keyword">then</span><br>
<span class=
"ident2">PS1</span>=<span class=
"literal">"%m:%~%# "</span><br>
<span class="keyword">elif</span> [ <span class=
"literal">"</span><span class=
"ident2">$SHELL</span><span class="literal">"</span> = <span class="literal">"/bin/ash"</span> ]; <span class="keyword">then</span><br>
<span class=
"ident2">PS1</span>=<span class="literal">"$ "</span><br>
<span class="keyword">else</span><br>
<span class=
"ident2">PS1</span>=<span class=
"literal">'\u@\h:\w\$ '</span><br>
<span class="keyword">fi</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>add:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">if</span> [ <span class=
"literal">"</span><span class="ident2">$TERM</span><span class=
"literal">"</span> = <span class=
"literal">"xterm"</span> ]; <span class=
"keyword">then</span><br>
<span class=
"ident2">PS1</span>=<span class="literal">"</span><span class=
"keyword2">\</span><span class=
"literal">033]2;</span><span class=
"keyword2">\</span><span class="literal">u@</span><span class=
"keyword2">\</span><span class="literal">h:</span><span class=
"keyword2">\</span><span class="literal">w</span><span class=
"keyword2">\</span><span class=
"literal">007bash$ "</span><br>
<span class="keyword">fi</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>The terminator "\007" is a problem area.
<strong>XTerm</strong> 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.</p>
<p>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.</p>
<p>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:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="comment">#!/bin/ksh</span><br>
<span class=
"comment"># Echo the current X term title bar to standard output.</span><br>
<span class=
"comment"># Written by Icarus Sparry <icarus@bath.ac.uk> 11 Apr 1997</span><br>
<span class="comment">#</span><br>
<span class="keyword">exec</span> </dev/tty<br>
<span class="ident2">old</span>=<span class=
"keyword2">$(</span>stty -g<span class=
"keyword2">)</span><br>
stty raw -echo min <span class=
"number">0</span> <span class=
"keyword">time</span> <span class=
"ident2">${1</span><span class=
"keyword2">-</span>10<span class="ident2">}</span><br>
<span class="keyword">print</span> <span class=
"literal">"</span><span class="keyword2">\</span><span class=
"literal">033[21t</span><span class=
"keyword2">\</span><span class=
"literal">c"</span> > /dev/tty<br>
<span class="ident2">IFS</span>=<span class=
"literal">''</span> <span class=
"keyword">read</span> -r a<br>
stty <span class="ident2">$old</span><br>
<span class="ident2">b</span>=<span class=
"ident2">${a</span><span class=
"keyword2">#</span>???<span class="ident2">}</span><br>
<span class="keyword">print</span> -R <span class=
"literal">"</span><span class="ident2">${b</span><span class=
"keyword2">%</span>??<span class="ident2">}</span><span class=
"literal">"</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>But it is possible to avoid escape sequences altogether (from
Hemant Shah <shah@typhoon.xnet.com>):</p>
<blockquote>
<pre class="code-block">
$ xprop -id $WINDOWID | grep WM_NAME
WM_NAME(STRING) = "this is my title"
current_title=$(xprop -id $WINDOWID | grep WM_NAME | cut -d= -f2)
</pre>
</blockquote>
<p>Here's another source of information: <a href=
"http://tldp.org/HOWTO/Xterm-Title.html">Xterm-Title
HowTo</a></p>
<h3 id="how2_blink-id"><a name="how2_blink" id="how2_blink">How
do I make the cursor blink?</a></h3>
<p>Standard xterm does not implement a blinking cursor. Some of
the variations do: dtterm, GNOME Terminal, and modern xterm (from
mid 1999, <a href="/xterm/xterm.log.html#xterm_107">patch
107</a>).</p>
<h2 id="frequent_problems-id"><a name="frequent_problems" id=
"frequent_problems">Frequent problems</a></h2>
<ul>
<li>
<a href="#problems_starting">Starting xterm, or not</a>
<ul>
<li><a href="#no_ptys">Xterm does not run (no available
pty's)</a></li>
<li><a href="#no_termcap">I need /etc/termcap</a></li>
<li><a href="#no_libpath">Why does $LD_LIBRARY_PATH get
reset?</a></li>
<li><a href="#no_ls_and_e">Why do the -e and -ls options
not work together?</a></li>
<li><a href="#setup_resize">Why is my screen size not
set?</a></li>
<li><a href="#tiny_menus">Why are the menus tiny?</a></li>
</ul>
</li>
<li>
<a href="#problems_fonts">Font problems</a>
<ul>
<li><a href="#no_altchar">My terminal doesn't show box
characters</a></li>
<li><a href="#scaled_font">The bold font is ugly</a></li>
<li><a href="#little_dot">I see little dots on the
screen</a></li>
<li><a href="#no_russian">My terminal doesn't display
Cyrillic characters</a></li>
<li><a href="#utf8_fonts">I see boxes instead of characters
in uxterm</a></li>
<li><a href="#utf8_badcode">I see question-marks instead of
characters in uxterm</a></li>
<li><a href="#slow_menus">The first popup menu is very
slow</a></li>
</ul>
</li>
<li>
<a href="#problems_keyboard">Keyboard problems</a>
<ul>
<li><a href="#xterm_8bits">Why can't I input 8-bit
characters?</a></li>
<li><a href="#xterm_erase">Why doesn't my delete key
work?</a></li>
<li><a href="#xterm_erased">Why did my delete key stop
working?</a></li>
<li><a href="#xterm_xmodmap">Well, how can I set my delete
key?</a></li>
<li><a href="#xterm_keypad">Why doesn't my keypad work?</a></li>
<li><a href="#xterm_modother">How can my program
distinguish control-I from tab?</a></li>
<li><a href="#xterm_pageup">Why can't I use the
pageup/pagedown keys?</a></li>
<li><a href="#xterm_pc_style">Why can't I use the home/end
keys?</a></li>
<li><a href="#xterm_arrows">Why can't I use the cursor keys
in (whatever) shell?</a></li>
<li><a href="#bash_meta_mode">Alt-keys do not work in
bash</a></li>
</ul>
</li>
<li>
<a href="#problems_colors">Colors and other graphic
rendition</a>
<ul>
<li><a href="#no_color">My terminal doesn't recognize
color</a></li>
<li><a href="#xterm_terminfo">What $TERM should I use?</a></li>
<li><a href="#xterm_hilite">Reverse video is not reset</a></li>
<li><a href="#vim_16colors">My colors changed in vim</a></li>
<li><a href="#bold_vs_16colors">Aren't bright colors the
same as bold?</a></li>
<li><a href="#color_by_number">Can I set a color by its
number?</a></li>
<li><a href="#dont_like_blue">I don't like that shade of
blue</a></li>
<li><a href="#why_no_italics">Why doesn't xterm support
italics?</a></li>
<li><a href="#grep_colors">"grep --color" does not show the
right output</a></li>
<li><a href="#vt100_wrapping">That description of wrapping
is odd, say more?</a></li>
<li><a href="#bce_oddness">That color scheme is odd, say
more?</a></li>
</ul>
</li>
<li>
<a href="#problems_weird">Odd behavior</a>
<ul>
<li><a href="#xterm_paste">Why can't I select/paste in
xterm?</a></li>
<li><a href="#xterm_select_clipboard">Why can't I
select/paste to/from other programs?</a></li>
<li><a href="#xterm_tabs">Why can't I select tab-characters
in xterm?</a></li>
<li><a href="#xterm_paste_nl">Can bracketed-paste solve my
problems?</a></li>
<li><a href="#xterm_resize">FVWM does weird things when I
try to resize xterm</a></li>
<li><a href="#xterm_tite">Why doesn't the screen clear when
running vi?</a></li>
<li><a href="#xterm_form_feed">Why doesn't the screen clear
when I type control/L?</a></li>
<li><a href="#xterm_vite">Why is the cursor misplaced after
running vi?</a></li>
<li><a href="#narrowproto">Why doesn't the scrollbar
work?</a></li>
<li><a href="#xaw_scrollbars">Can I improve the
scrollbars?</a></li>
<li><a href="#scroll_speed">Can I improve the scrolling
speed?</a></li>
<li><a href="#window_ops">Why can't my program read the
window title?</a></li>
<li><a href="#window_ops2">Why can't my program set the
window size?</a></li>
<li><a href="#compiz_bugs">Why is the text in the wrong
place?</a></li>
</ul>
</li>
<li><a href="#my_xdefaults">Sample .Xdefaults Color-Settings
for XTerm</a></li>
<li><a href="#warning_msg">What is this warning message?</a></li>
</ul>
<h3 id="problems_starting-id"><a name="problems_starting" id=
"problems_starting">Starting xterm, or not</a></h3>
<h4 id="no_ptys-id"><a name="no_ptys" id=
"no_ptys"><strong>XTerm</strong> does not run (no available
pty's)</a></h4>
<p>Your copy of xterm may not have enough permissions to use
existing pty's:</p>
<ul>
<li>you may have to make xterm run setuid to root (though newer
systems have wrappers that make this unnecessary).</li>
<li>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.</li>
<li>newer systems (with Unix98 pty's) have a single entry under
/dev which has to have the right permissions. For example:
<blockquote>
<pre class="code-block">
# ls -l /dev/ptmx
crw-rw---- 1 root tty 5, 2 Aug 21 20:19 /dev/ptmx
</pre>
</blockquote>
</li>
</ul>
<p>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
<code>/usr/src/linux/Documentation</code>).</p>
<p>See also the MAKEDEV script, which usually exists under
/dev.</p>
<h4 id="no_termcap-id"><a name="no_termcap" id="no_termcap">I
need /etc/termcap</a></h4>
<p>If you have a termcap version of xterm on a system with no
termcap libraries, you may also be missing /etc/termcap.</p>
<p>A workaround is to copy /usr/X11R6/lib/X11/etc/xterm.termcap
to /etc/termcap.</p>
<p>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.</p>
<h4 id="no_libpath-id"><a name="no_libpath" id="no_libpath">Why
does $LD_LIBRARY_PATH get reset?</a></h4>
<p>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
<code>$PATH</code> and <code>$LD_LIBRARY_PATH</code>, since they
affect the choice of which programs are run if not specified via
a full pathname.</p>
<p>This means, for example, that if you attempt to run</p>
<blockquote>
<pre class="code-block">
xterm -e foo
</pre>
</blockquote>
<p>where <code>foo</code> is a program that uses shared libraries
in <code>/usr/local/lib</code>, then the command will fail,
because <code>/usr/local/lib</code> is not considered part of
<code>root</code>'s environment.</p>
<p>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.</p>
<h4 id="no_ls_and_e-id"><a name="no_ls_and_e" id=
"no_ls_and_e">Why do the -e and -ls options not work
together?</a></h4>
<p><strong>XTerm</strong> has two useful options for controlling
the shell that is run:</p>
<dl>
<dt>-e</dt>
<dd>tells xterm to execute a command using the remaining
parameters after this option.</dd>
<dt>-ls</dt>
<dd>tells xterm to invoke a login shell, making it read your
<code>.login</code> file, for instance.</dd>
</dl>
<p>The two are not compatible. If you specify both, xterm uses
<code>-e</code>, and if that fails for whatever reason will fall
through to the <code>-ls</code> option. It cannot (in general)
combine the two, since some shells permit this (e.g., bash), and
others do not (e.g., tcsh).</p>
<h4 id="setup_resize-id"><a name="setup_resize" id=
"setup_resize">Why is my screen size not set?</a></h4>
<p>Well, it may be set, but not correctly. You may notice these
symptoms:</p>
<ul>
<li>When editing with vi, you cannot see the beginning of the
file, or</li>
<li>Running
<blockquote>
<pre class="code-block">
stty -a
</pre>
</blockquote>
<p>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.</p>
</li>
</ul>
<p><strong>XTerm</strong> 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:</p>
<ul>
<li><strong>XTerm</strong> itself may have been built
incorrectly (the #ifdef's that make the logic work are
inactive).</li>
<li>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.</li>
<li>You may be running su'd to another account. SIGWINCH is
just another signal; signals do not propagate for security
reasons.</li>
</ul>
<p>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.</p>
<p>You may be able to use the <em>resize</em> 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:</p>
<blockquote>
<pre class="code-block">
stty rows 24 columns 80
</pre>
</blockquote>
<p>Most full-screen applications also check if the $LINES and
$COLUMNS variables are set, using those values to override the
terminal description:</p>
<blockquote>
<pre class="code-block">
setenv LINES 24
setenv COLUMNS 80
</pre>
</blockquote>
<p>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.</p>
<h4 id="tiny_menus-id"><a name="tiny_menus" id="tiny_menus">Why
are the menus tiny?</a></h4>
<p>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).</p>
<p>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:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"ident2">geometry</span>:<span class=
"literal"> 80x24</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>while this applies only to the VT100 widget (which is probably
what you intended):</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>.<span class=
"keyword">VT100</span>.<span class=
"ident2">geometry</span>:<span class=
"literal"> 80x24</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>or better yet (to allow for the toolbar option, which uses a
level of widget hierarchy):</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">geometry</span>:<span class=
"literal"> 80x24</span><br>
<!--atr2html}}--></p>
</blockquote>
<h3 id="problems_fonts-id"><a name="problems_fonts" id=
"problems_fonts">Font problems</a></h3>
<h4 id="no_altchar-id"><a name="no_altchar" id="no_altchar">My
terminal doesn't show box characters</a></h4>
<p><strong>XTerm</strong> 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 <em>xfd</em> to display
the font.</p>
<p>Modern xterm can form its own line-drawing characters (see
<a href="/xterm/xterm.log.html#xterm_90">patch 90</a>, 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.</p>
<p>You may also have a problem with the terminfo description. As
distributed, the X11R6 terminfo for xterm does not have the
<em>acsc</em> string defined, so most implementations of curses
do not try to use the alternate character set.</p>
<p>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.</p>
<h4 id="scaled_font-id"><a name="scaled_font" id=
"scaled_font">The bold font is ugly</a></h4>
<p><strong>XTerm</strong> 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:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
FontPath "<span class="literal">/usr/lib/X11/fonts/100dpi/:unscaled</span>"<br>
FontPath "<span class="literal">/usr/lib/X11/fonts/75dpi/:unscaled</span>"<br>
FontPath "<span class="literal">/usr/lib/X11/fonts/misc/:unscaled</span>"<br>
<!--atr2html}}--></p>
</blockquote>
<p>You can suppress xterm's overstriking for bold fonts using the
<code>alwaysBoldMode</code> 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.</p>
<h4 id="little_dot-id"><a name="little_dot" id="little_dot">I see
little dots on the screen</a></h4>
<p>Well, I do. Perhaps you do not. It depends on the fonts you
choose, and how you use them.</p>
<p>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, <a href=
"xterm.log.html#xterm_85">patch 85</a>). 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.</p>
<h4 id="no_russian-id"><a name="no_russian" id="no_russian">My
terminal doesn't display Cyrillic characters</a></h4>
<p>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 <a href=
"xterm.log.html#xterm_175">patch 175</a> to add an option
(<code>-k8</code>) and corresponding resource settings to allow
them to customize their environment. Here is a <a href=
"/archives/xterm/koi8-term">sample script</a> and <a href=
"/archives/xterm/KOI8Term">resource file</a> which I use for
testing this configuration.</p>
<h4 id="utf8_fonts-id"><a name="utf8_fonts" id="utf8_fonts">I see
boxes instead of characters in uxterm</a></h4>
<p><strong>XTerm</strong> 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 <code>uxterm</code>. However, your X resource
settings may be the source of the problem.</p>
<p>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.</p>
<p><strong>XTerm</strong> 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 <code>uxterm</code>. The
latter is where an overbroad pattern can cause xterm to use a
different font than you expect.</p>
<p>Suppose your resource setting includes this pattern</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class="keyword">VT100</span>*<span class=
"ident2">font</span>:<span class=
"literal"> fixed</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>It could be interpreted as this:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class="keyword">VT100</span>.<span class=
"ident2">font</span>:<span class=
"literal"> fixed</span><br>
*<span class="keyword">VT100</span>.<span class=
"ident2">utf8Fonts</span>.<span class=
"ident2">font</span>:<span class=
"literal"> fixed</span><br>
<!--atr2html}}--></p>
</blockquote>
<p><strong>XTerm</strong> uses the <code>utf8Fonts</code>
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</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class="keyword">VT100</span>.<span class=
"ident2">font</span>:<span class=
"literal"> fixed</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>it would be unambiguous, and not modify the
<code>utf8Fonts</code> value.</p>
<h4><a name="utf8_badcode" id="utf8_badcode">I see question-marks
instead of characters in uxterm</a></h4>
<p>You may be seeing a question mark in a black diamond, like
this:</p>
<blockquote>
<p>�</p>
</blockquote>
<p>That is called the Unicode <em>replacement character</em>. It
is used when a program is told to display a character which is
not in the Unicode system. The program <em>replaces</em> the
illegal/invalid character with this symbol. That is different
from <em>boxes</em>, which xterm displays when it has nothing in
the current font for a valid Unicode character.</p>
<p>Unicode's rules are oriented toward handling <em>input</em> in
different encodings, and <em>displaying</em> the corresponding
Unicode value. Although Unicode has rules and a definition for
the valid characters, different programs may handle invalid input
in different ways. <a href="bad-utf8/">This page</a> gives an
overview of how xterm may differ from other programs in that
regard.</p>
<h4 id="slow_menus-id"><a name="slow_menus" id="slow_menus">The
first popup menu is very slow</a></h4>
<p>Some users report that when starting xterm, it is very slow,
that their computer's CPU time increases, etc.</p>
<p>This is a longstanding bug in the X libraries. There is a
workaround using a resource setting for xterm.</p>
<h5 id="slow_menus_details-id">Details</h5>
<p><strong>XTerm</strong> 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.</p>
<p>The Athena widgets <code>XawInitializeWidgetSet</code>
function goes through several levels down to the X library
<code>_XlcAddUtf8LocaleConverters</code> function to call
<code>create_tocs_conv</code> 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.</p>
<p>If your current locale uses <em>UTF-8</em> encoding, this will
read a long list of bitmap fonts—everything whose
<em>encoding</em> might be useful for displaying the menus. For
example, this list (from <code>lcUTF8.c</code>) which dates from
around 2000 is the core of the problem:</p>
<blockquote class="code-block">
<p>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</p>
</blockquote>
<p>However, xterm is going to use only the characters shown in
the popup menus. It is unlikely that you need Chinese fonts for
that.</p>
<h5 id="slow_menus_solution-id">Solution</h5>
<p><strong>XTerm</strong>'s <code>menuLocale</code> resource can
be set to an explicit value, e.g., "C" to override the current
locale as seen by this initialization debacle.</p>
<h5 id="slow_menus_limits-id">Limitations</h5>
<p>The workaround does not prevent some hacker from "improving"
the X libraries still further.</p>
<h3 id="problems_keyboard-id"><a name="problems_keyboard" id=
"problems_keyboard">Keyboard problems</a></h3>
<h4 id="xterm_8bits-id"><a name="xterm_8bits" id=
"xterm_8bits">Why can't I input 8-bit characters?</a></h4>
<p>You must have the <code>eightBitInput</code> resource set to
do this.</p>
<h4 id="xterm_erase-id"><a name="xterm_erase" id=
"xterm_erase">Why doesn't my delete key work?</a></h4>
<p>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).</p>
<p>The underlying problem is that we've accumulated three things
that are being equated as "Delete":</p>
<blockquote>
<pre class="code-block">
ASCII BS (backspace, code 8)
ASCII DEL (delete. code 127)
VT220 "remove" aka "delete" (ESC [ 3 ~)
</pre>
</blockquote>
<p>You are probably talking about the <strong>backarrow</strong>
key (on my keyboard, at the upper right of the QWERTY block), or
the key labeled <strong>delete</strong> 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
<code>^?</code>). You would use a control/H to obtain a backspace
on a real VT220.</p>
<p>The reason why <code>BS</code> and <code>DEL</code> are of
special interest is that on Unix, the <code>stty</code> command
and the underlying termios/termio system calls allow only
single-byte codes to be assigned to special functions such as
<code>erase</code>. For instance, you could see something like
this on your terminal:</p>
<blockquote>
<pre class="code-block">
$ 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 ff0
isig -icanon -iexten -echo -echoe -echok -echonl -noflsh -xcase -tostop -echoprt
-echoctl -echoke
</pre>
</blockquote>
<p>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.</p>
<p>Modern xterm (since <a href=
"/xterm/xterm.log.html#xterm_83">patch #83</a> in 1998) provides
a resource toggle <em>backarrowKey</em> (and an escape sequence
from VT320) that changes this key between the two styles
(backspace or delete).</p>
<p>With modern xterm <a href=
"/xterm/xterm.log.html#xterm_95">patch 95</a> (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
<em>kbs</em> (backspace key). This feature is controlled by the
resource setting <em>ptyInitialErase</em>.</p>
<h4 id="xterm_erased-id"><a name="xterm_erased" id=
"xterm_erased">Why did my delete key stop working?</a></h4>
<p>Well, something changed. You have to determine what did.</p>
<p>This may be because an upgrade introduced different X resource
settings, or because you are using the newer xterm with the
<em>ptyInitialErase</em> resource (or perhaps both). Use</p>
<blockquote>
<pre class="code-block">
appres XTerm
</pre>
</blockquote>
<p>to see the X resources that you are using, in particular the
<code>translation</code> (or <code>Translation</code>) resource
for the vt100 widget.</p>
<p>One unexpected scenario came out of hiding when I was
implementing the <em>ptyInitialErase</em> 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 <code>stty erase</code>
character is either backspace (^H) or delete (^?).</p>
<p>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 <kbd>remove</kbd> assigned to the
key Delete.</p>
<p>However, the <em>screen</em> program prefers to make the
termcap delete (<code>kD</code>) an <escape>[3~, which
corresponds to the VT220 <kbd>remove</kbd> key. If $TERMCAP is
set when starting <em>screen</em>, 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
<a href="/xterm/xterm.log.html#xterm_129">patch 129</a>), that
the problem really was because termcap <code>kD</code> should
delete the character at the current position. So it cannot be the
same as <code>stty erase</code>.</p>
<p>As a matter of fact, <code>stty erase</code> has to be a
single character, so <escape>[3~ would not work anyway.</p>
<h4 id="xterm_xmodmap-id"><a name="xterm_xmodmap" id=
"xterm_xmodmap">Well, how can I set my delete key?</a></h4>
<p>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 <em>xmodmap</em>, e.g.,</p>
<blockquote>
<pre class="code-block">
keysym BackSpace = Delete
</pre>
</blockquote>
<p>or</p>
<blockquote>
<pre class="code-block">
keycode 22 = 0xff08
</pre>
</blockquote>
<p>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').</p>
<p>Alternatively, you can set resources. This works reasonably
well for environments where you have different versions of xterm,
e.g.,</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">translations</span>:<span class=
"literal"> #override \n\<br>
<Key>Delete: string(</span><span class="number">0x7f</span><span class="literal">)</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>I do not do that either, because it is not flexible. Not all
programs use the same sense of <code>stty erase</code>; 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
<code>keymap()</code> 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
<code>backarrowKey</code> <code>backarrowKeyIsErase</code> and
<code>deleteIsDEL</code> as well as <code>sunKeyboard</code>.</p>
<h4 id="xterm_keypad-id"><a name="xterm_keypad" id=
"xterm_keypad">Why doesn't my keypad work?</a></h4>
<p>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.</p>
<p>Here's a picture of the VT100 numeric keypad:</p>
<blockquote>
<pre class="code-block">
+-----+-----+-----+-----+
| PF1 | PF2 | PF3 | PF4 |
+-----+-----+-----+-----+
| 7 | 8 | 9 | - |
+-----+-----+-----+-----+
| 4 | 5 | 6 | , |
+-----+-----+-----+-----+
| 1 | 2 | 3 | |
+-----+-----+-----+ ENT +
| 0 | . | |
+-----+-----+-----+-----+
</pre>
</blockquote>
<p>and the similar Sun and PC keypads:</p>
<blockquote>
<pre class="code-block">
+-----+-----+-----+-----+
| NUM | / | * | - |
+-----+-----+-----+-----+
| 7 | 8 | 9 | |
+-----+-----+-----+ + +
| 4 | 5 | 6 | |
+-----+-----+-----+-----+
| 1 | 2 | 3 | |
+-----+-----+-----+ ENT +
| 0 | . | |
+-----+-----+-----+-----+
</pre>
</blockquote>
<p>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.</p>
<p>VT220 emulation uses the VT100 numeric keypad as well as a
6-key editing keypad. Here's a picture of the VT220 editing
keypad:</p>
<blockquote>
<pre class="code-block">
+--------+--------+--------+
| Find | Insert | Remove |
+--------+--------+--------+
| Select | Prev | Next |
+--------+--------+--------+
</pre>
</blockquote>
<p>and the similar Sun and PC keypads:</p>
<blockquote>
<pre class="code-block">
+--------+--------+--------+
| Insert | Home | PageUp |
+--------+--------+--------+
| Delete | End | PageDn |
+--------+--------+--------+
</pre>
</blockquote>
<p>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:</p>
<blockquote>
<pre class="code-block">
+--------+--------+--------+
| Insert | Find | Prev |
+--------+--------+--------+
| Remove | Select | Next |
+--------+--------+--------+
</pre>
</blockquote>
<p>I test the keyboard (for VT52/VT100/VT220) using <a href=
"/vttest/vttest.html">vttest</a>. If you find (or think that you
have found) a problem with the keyboard handling of xterm, please
test it with vttest first.</p>
<p>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.</p>
<p>In 2014, I noticed <a href=
"http://www.neilvandyke.org/racket-charterm/">a comment</a>,
which relates to the PF1-PF4 assignment, but also to the use of
function-key modifiers.<br>
Because that is a digression, I have expanded it in a <a href=
"/xterm/xterm-function-keys.html">separate page</a>.</p>
<h4 id="xterm_modother-id"><a name="xterm_modother" id=
"xterm_modother">How can my program distinguish control-I from
tab?</a></h4>
<p>Your program can use xterm's <a href=
"manpage/xterm.html#VT100-Widget-Resources:modifyOtherKeys">modifyOtherKeys</a>
feature, e.g., using a <a name=
"h4-Functions-using-CSI-_-ordered-by-the-final-character-lparen-s-rparen:CSI-gt-Pp;Pv-m.1EB3"
id=
"h4-Functions-using-CSI-_-ordered-by-the-final-character-lparen-s-rparen:CSI-gt-Pp;Pv-m.1EB3">
control sequence</a> such as</p>
<blockquote>
<pre class="code-block">
\033 [ > 4 ; 2 m
</pre>
</blockquote>
<p>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 <tt>tab</tt>
key would send a <em>tab</em>, but
<em>control-<strong>i</strong></em> would send</p>
<blockquote>
<pre class="code-block">
\033 [ 2 7 ; 5 ; 1 0 5 ~
</pre>
</blockquote>
<p>while <em>control-shift-<strong>i</strong></em> would send</p>
<blockquote>
<pre class="code-block">
\033 [ 2 7 ; 6 ; 7 3 ~
</pre>
</blockquote>
<p>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:</p>
<blockquote>
<pre class="code-block">
\033 [ > 4 m
</pre>
</blockquote>
<p>In 2019, Bram Moolenaar asked for more details about modifying
<em>other keys</em>; I have expanded that in a <a href=
"/xterm/modified-keys.html">separate page</a>.</p>
<h4 id="xterm_pageup-id"><a name="xterm_pageup" id=
"xterm_pageup">Why can't I use the pageup/pagedown keys?</a></h4>
<p>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 <a href=
"xterm.faq.html#bug_xterm_r6">xterm</a>.</p>
<p>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:</p>
<blockquote>
<pre class="code-block">
/usr/lib/X11/app-defaults/XTerm
/usr/openwin/lib/app-defaults
</pre>
</blockquote>
<p>using a symbolic link to relate the two. Later releases of
Solaris, e.g., 8-10 omitted the former location.<br>
Solaris 11 provides modern xterm (<a href=
"/xterm/xterm.log.html#xterm_271">patch #271</a>), and does not
have this problem.</p>
<p>As of February 2014, I was able to verify that AIX and HPUX
have updated to modern xterm, e.g.,</p>
<ul>
<li><a href="/xterm/xterm.log.html#xterm_180">patch #180</a> on
HPUX 11.31,</li>
<li><a href="/xterm/xterm.log.html#xterm_222">patch #222</a> on
AIX 6.1 and 7.1,</li>
</ul>
<p>Older AIX and HPUX releases distributed the X Consortium
(1994) app-defaults file.</p>
<blockquote>
<p style="font-variant:small-caps">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</p>
<blockquote>
<pre class="code-block">
/usr/lpp/X11/lib/X11/app-defaults
</pre>
</blockquote>
<p style="font-variant:small-caps">There were no other changes
to the file. Someone at IBM blundered.<br>
In patch #252, I ensured that my copyright notice is on those
files (I am the sole author, and can do that).</p>
</blockquote>
<p>Use the translations in the system's app-defaults file as a
guide. The relevant section of the app-default file looks
like</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class="keyword">VT100</span>.<span class=
"ident2">translations</span>:<span class=
"literal"> #override \<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_0: string(</span><span class="number">0</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_1: string(</span><span class="number">1</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_2: string(</span><span class="number">2</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_3: string(</span><span class="number">3</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_4: string(</span><span class="number">4</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_5: string(</span><span class="number">5</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_6: string(</span><span class="number">6</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_7: string(</span><span class="number">7</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_8: string(</span><span class="number">8</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_9: string(</span><span class="number">9</span><span class="literal">)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_Add: string(+)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_Decimal: string(.)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_Divide: string(/)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_Enter: string(\015)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_Equal: string(=)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_Multiply: string(*)\n\<br>
@Num_Lock</span><span class="keyword"><Key></span><span class="literal">KP_Subtract: string(-)\n\<br>
</span><span class="keyword"><Key></span><span class="literal">Prior:scroll-back(</span><span class="number">1</span><span class="literal">,page)\n\<br>
</span><span class="keyword"><Key></span><span class="literal">Next:scroll-forw(</span><span class="number">1</span><span class="literal">,page)\n\<br>
</span><span class="keyword"><Key></span><span class="literal">F16: start-extend() select-end(PRIMARY, CUT_BUFFER0, CLIPBOARD) \n\<br>
</span><span class="keyword"><Key></span><span class="literal">F18: insert-selection(PRIMARY, CLIPBOARD) \n\<br>
</span><span class="keyword"><Key></span><span class="literal">F27: scroll-back(</span><span class="number">100</span><span class="literal">,page) \n\<br>
</span><span class="keyword"><Key></span><span class="literal">R13: scroll-forw(</span><span class="number">100</span><span class="literal">,page) \n\<br>
</span><span class="keyword"><Key></span><span class="literal">Home: scroll-back(</span><span class="number">100</span><span class="literal">,page) \n\<br>
</span><span class="keyword"><Key></span><span class="literal">End: scroll-forw(</span><span class="number">100</span><span class="literal">,page) \n</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>For example, a more-specific pattern for the resource name
lets you override:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">translations</span>:<span class=
"literal"> #override \n\<br>
~Shift</span><span class="keyword"><Key></span><span class="literal">Home: string(\033[</span><span class="number">1</span><span class="literal">~)\n\<br>
~Shift</span><span class="keyword"><Key></span><span class="literal">End: string(\033[</span><span class="number">4</span><span class="literal">~)\n\<br>
~Shift</span><span class="keyword"><Key></span><span class="literal">Prior: string(\033[</span><span class="number">5</span><span class="literal">~)\n\<br>
~Shift</span><span class="keyword"><Key></span><span class="literal">Next: string(\033[</span><span class="number">6</span><span class="literal">~)\n\<br>
Shift</span><span class="keyword"><Key></span><span class="literal">Prior: scroll-back(</span><span class="number">1</span><span class="literal">,page) \n\<br>
Shift</span><span class="keyword"><Key></span><span class="literal">Next: scroll-forw(</span><span class="number">1</span><span class="literal">,page) \n\<br>
Shift</span><span class="keyword"><Key></span><span class="literal">Home: scroll-back(</span><span class="number">100</span><span class="literal">,page) \n\<br>
Shift</span><span class="keyword"><Key></span><span class="literal">End: scroll-forw(</span><span class="number">100</span><span class="literal">,page) \n</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>makes the home/end and pageup/pagedown keys usable by your
editor, while leaving their shifted equivalents available for the
scrollbar.</p>
<h4 id="xterm_pc_style-id"><a name="xterm_pc_style" id=
"xterm_pc_style">Why can't I use the home/end keys?</a></h4>
<p>This is a long story, unless you are referring to X Consortium
<a href="#bug_xterm_r6">xterm</a>. That program is simply broken
in this respect.</p>
<p>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.,</p>
<blockquote>
<pre class="code-block">
ESC [ H
ESC [ F
</pre>
</blockquote>
<p>for normal mode, and</p>
<blockquote>
<pre class="code-block">
ESC O H
ESC O F
</pre>
</blockquote>
<p>for cursor application mode.</p>
<p>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 <a href=
"xterm.faq.html#xterm_keypad">match</a>. At that point, neither
of us knew enough to make a good case for this.</p>
<p>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 <a href=
"/xterm/xterm.log.html#xterm_88">"stable" patch #88</a>, which is
essentially the version distributed with XFree86 3.3.x.</p>
<dl>
<dt><em>NOTE</em>:</dt>
<dd>
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:
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class="ident2">sunKeyboard</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>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 <a href=
"https://bugzilla.redhat.com/show_bug.cgi?id=100695">#100695</a>
quoted a suggested <a href=
"https://bugzilla.redhat.com/attachment.cgi?id=93107&action=diff">
patch</a> which shows that the package had overridden the
xterm behavior for shifted function keys. See <a href=
"xterm.faq.html#xterm_xmodmap">this</a> for more
discussion.</p>
</dd>
</dl>
<p>But xterm continues to evolve past the stable patch #88. The
keyboard support was still unsatisfactory for two reasons:</p>
<ul>
<li>some users wanted to be able to use applications that
detected whether the control key was pressed (e.g.,
control/F1).</li>
<li>the compromises made for <code>xkb</code> with X11R6
interfered with xterm's use of the NumLock key for the numeric
keypad.</li>
</ul>
<p>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
<code>sunKeyboard</code> resource. Partway through that, I was
asked to do similar cleanup and redesign of the backspace and
delete key handling, e.g., the <a href=
"xterm.faq.html#xterm_erased">ptyInitialErase</a> 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.</p>
<p>For example, at this time (2001/9/4):</p>
<ul>
<li>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 <code>kbs</code> from <code>^H</code> to
<code>^?</code>. As noted, the terminfo I wrote for XFree86
3.3.x has an error. Setting
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class="ident2">sunKeyboard</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>in the app-defaults file fixes the problem with xterm-88,
which was that I documented in the terminfo the behavior
<em>with</em> that resource set. Similarly, setting</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class="ident2">backarrowKey</span>:<span class=
"literal"> </span><span class=
"keyword">false</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>is one way to address Debian's change to
<code>kbs</code>.</p>
</li>
<li>Debian unstable is xterm-149. Other than omitting the color
resources from the app-defaults file, I see that it sets
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class=
"ident2">backarrowKeyIsErase</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>which would not affect the home/end keys. (The color
resources are redundant, so that is not a problem
either).</p>
</li>
</ul>
<p><a href="/xterm/XTerm-debian-88c">Here is a resource file</a>
which I tested with xterm-88c, xterm-149 and xterm-158, using
$TERM set to xterm-debian:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="comment">! $Id: xterm.faq.html,v 1.169
2012/02/05 11:58:56 tom Exp $<br></span><span class=
"comment">! Settings to make xterm-88c work as expected for Debian.<br>
</span> <span class="comment">!<br></span><span class=
"comment">! Patch #88 was the basis for XFree86 3.3.1 xterm. There were a few additions<br>
</span> <span class=
"comment">! through patch 88c, to incorporate the ptyInitialErase resource. Debian uses<br>
</span> <span class=
"comment">! the VT220-style keyboard, which at #88 was the xterm-xfree86 terminfo entry,<br>
</span> <span class=
"comment">! with one change: kbs changed from ^H to ^?.<br>
</span> <span class="comment">!<br></span><span class=
"comment">! After patch 88, I started work on keyboard changes. The result was that the<br>
</span> <span class=
"comment">! xterm-xfree86 terminfo entry was set to the PC-style keyboard, and I added<br>
</span> <span class=
"comment">! xterm-vt220, which corresponded mostly to the older (patch-88) version of the<br>
</span> <span class=
"comment">! xterm-xfree86 terminfo entry.<br></span> <br>
<span class=
"comment">! The terminfo with patch #88 assumed sunKeyboard was set (actually a bug, but<br>
</span> <span class=
"comment">! also assumed in Debian).<br></span><span class="comment">!<br>
</span> <span class=
"comment">! A different problem (addressed after patch #88) is that if you wanted to use<br>
</span> <span class=
"comment">! a VT100/VT220-style numeric keypad's escape sequences, you had to have<br>
</span> <span class=
"comment">! NumLock set. Otherwise, in keypad application mode, the keys would transmit<br>
</span> <span class=
"comment">! only the PC-style escape sequences corresponding to the key labels, e.g., the<br>
</span> <span class=
"comment">! page-up string rather than the escape sequence for keypad-9.<br>
</span> <span class="keyword">XTerm</span>*<span class=
"ident2">sunKeyboard</span>:<span class=
"literal"> </span><span class="keyword">true</span><br>
<br>
<span class=
"comment">! These settings overlap to some extent (backarrowKeys says to send a 127 for<br>
</span> <span class=
"comment">! the "backspace" key, and ptyInitialErase says to use the pty's initial sense<br>
</span> <span class=
"comment">! of the erase character, which is reported to be the same on Linux).<br>
</span> <span class="keyword">XTerm</span>*<span class=
"ident2">backarrowKey</span>:<span class=
"literal"> </span><span class="keyword">false</span><br>
<span class="keyword">XTerm</span>*<span class=
"ident2">ptyInitialErase</span>:<span class=
"literal"> </span><span class="keyword">true</span><br>
<!--atr2html}}--></p>
</blockquote>
<h4 id="xterm_arrows-id"><a name="xterm_arrows" id=
"xterm_arrows">Why can't I use the cursor keys in (whatever)
shell?</a></h4>
<p>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.</p>
<p>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.</p>
<p>To see the difference between normal/application modes,
consider this example:</p>
<ul>
<li>In normal (non-application) mode, the terminal transmits a
down-arrow as \E[C, which happens to echo as a down-arrow.</li>
<li>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.</li>
</ul>
<p>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.</p>
<p>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 <code>smkx</code> and
<code>rmkx</code> capabilities. Terminfo entries are written
assuming that the application has initialized the terminal using
the <code>smkx</code> string before it is able to match the codes
given for the cursor or keypad keys.</p>
<h4 id="bash_meta_mode-id"><a name="bash_meta_mode" id=
"bash_meta_mode">Alt-keys do not work in bash</a></h4>
<p>See <a href=
"/ncurses/ncurses.faq.html#bash_meta_mode">Alt-keys do not work
in bash</a>.</p>
<h3 id="problems_colors-id"><a name="problems_colors" id=
"problems_colors">Colors and other graphic rendition</a></h3>
<h4 id="no_color-id"><a name="no_color" id="no_color">My terminal
doesn't recognize color</a></h4>
<p>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 <a href=
"xterm.faq.html#my_xdefaults">.Xdefaults</a> file.</p>
<p>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 <a href=
"xterm.faq.html#alloc_color">warning message</a> for this.</p>
<p>Check the terminal description, to see if it is installed
properly, e.g., for <a href=
"/ncurses/ncurses.faq.html#no_color">ncurses</a>, which uses
terminfo.</p>
<p>Finally, some applications (that do not interface properly
with terminfo or termcap) may need the environment variable
<a href="/ncurses/ncurses.faq.html#no_colorterm">$COLORTERM</a>
to be set.</p>
<h4 id="xterm_terminfo-id"><a name="xterm_terminfo" id=
"xterm_terminfo">What $TERM should I use?</a></h4>
<p><strong>XTerm</strong> provides in its sources both <a href=
"terminfo.html">terminfo</a> and <a href=
"termcap.html">termcap</a> files. They are designed to allow
scripting to override the most common choices, e.g., the
backspace key.</p>
<p>The <code>xterm-color</code> value for $TERM is a bad choice
for modern xterm because it is commonly used for a terminfo entry
which happens to not support <code>bce</code>. Complicating
matters, FreeBSD (after dithering for a few years on the matter)
introduced a bastardized version which implies the opposite sense
of <code>bce</code>, (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.</p>
<p>The most recent XFree86 version's terminal description
corresponds to <code>xterm-xfree86</code> (also distributed with
ncurses). I have continued to make changes; the most recent
version is simply named <code>xterm-new</code> (also distributed
with ncurses).</p>
<p>The term "<code>bce</code>" 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
<a href="/ncurses/ncurses.faq.html#bce_mismatches">ncurses
FAQ</a>. Unsurprisingly, ncurses supports xterm's behavior.</p>
<p>Curses libraries that support color know about
<code>bce</code> 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 <code>bce</code>, 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 <a href="/lynx/lynx-ncurses.html">page</a> 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 <code>bce</code>
does not work properly, for instance).</p>
<p>The <code>xterm-color</code> 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.</p>
<p>Some people recommend using <a href=
"/ncurses/terminfo.src.html#tic-xtermc"><code>xtermc</code></a>.
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.</p>
<h4 id="xterm_hilite-id"><a name="xterm_hilite" id=
"xterm_hilite">Reverse video is not reset</a></h4>
<p>When running <em>less</em> or other programs that do
highlighting, you see the highlighting not turned off
properly.</p>
<p>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.</p>
<p>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.,
<code>xterm-color</code>) and set the <code>termName</code>
resource accordingly in the app-defaults file for the system
which has the newer xterm.</p>
<p>However – see <a href=
"xterm.faq.html#xterm_terminfo">above</a>.</p>
<h4 id="vim_16colors-id"><a name="vim_16colors" id=
"vim_16colors">My colors changed in vim</a></h4>
<p>Some <code>vim</code> users may notice their colors change
after updating to <a href="/xterm/xterm.log.html#xterm_238">patch
238</a>. Before, some text would display in a dark color using a
bold font. Now, it displays in a bright color and normal
font.</p>
<p>This is not a bug, but the result of a feature
<em>tcap-query</em> 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.</p>
<p>Vim also asks how many colors the terminal supports. Since
<a href="/xterm/xterm.log.html#xterm_148">patch 148</a>, 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).</p>
<p>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.</p>
<p>Changing the color scheme to use bold where it is wanted will
make the colors work as before – and work consistently with
other terminals.</p>
<h4 id="bold_vs_16colors-id"><a name="bold_vs_16colors" id=
"bold_vs_16colors">Aren't bright colors the same as bold?</a></h4>
<p>No.</p>
<p>Actually, "bold" happens to be whatever the terminal shows
when it is sent the control-string that says "show bold".</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<h4 id="color_by_number-id"><a name="color_by_number" id=
"color_by_number">Can I set a color by its number?</a></h4>
<p>Well, yes: you can set a color in several ways:</p>
<ul>
<li>using the color <em>name</em></li>
<li>using an RGB <em>value</em></li>
<li>selecting an <em>index</em> from the color palette</li>
</ul>
<p>That last (an <em>index</em>) is what some people think of as
the <em>color number</em>. 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.</p>
<p>In my reply to <em><a href=
"http://unix.stackexchange.com/questions/269077/tput-setaf-color-table-how-to-determine-color-codes">
tput setaf color table? How to determine color codes?</a></em>, I
noted</p>
<blockquote>
<p>You may find this question/answer helpful as well:
<em><a href=
"https://stackoverflow.com/questions/27159322/rgb-values-of-the-colors-in-the-ansi-extended-colors-index-17-255">
RGB values of the colors in the Ansi extended colors index
(17-255)</a></em></p>
</blockquote>
<p>although both question and answer raise additional questions.
This FAQ is the logical place to answer those questions.</p>
<p>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.</p>
<p>The long answer is that the correct mapping depends on the
terminal — other terminals do not necessarily match
xterm.</p>
<p>From a shell script, you might use <a href=
"/ncurses/man/tput.1.html">tput</a> with a parameter to an escape
sequence referred to as <code>setaf</code> in the terminal
description. <code>tput</code> attaches no particular meaning to
the number. That actually depends upon the particular terminal
emulator.</p>
<p>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 <code>setf/setb</code> or
<code>setaf/setab</code>. Since the latter has the connotation of
"ANSI colors", you will see that used more often. The former
(<code>setf/setb</code>) switched the order for red/blue as noted
in <em><a href=
"/ncurses/ncurses.faq.html#interchanged_colors">Why are red/blue
interchanged?</a></em>, but in either case, the scheme was
established for just numbering the colors. There is no predefined
relationship between those numbers and RGB content.</p>
<p>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 <em><a href="#dont_like_blue">I don't like
that shade of blue</a></em>.</p>
<p>However, convention is often confused with standards. Because
xterm has been around a while, it is regarded as a standard by
some.</p>
<p>XTerm had color support before I began working on it at the
<a href="/xterm/xterm.html#history">end of 1995</a>. Some of this
was mentioned in XFree86's changelog:</p>
<blockquote>
<pre class="code-block">
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).
</pre>
</blockquote>
<p>and some was not:</p>
<ul>
<li>
<p>The “dynamic colors” feature came from a patch
written by Erik Fortune (at SGI). Someone applied this to the
XFree86 sources (probably early 1995).</p>
<p>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 <em>static</em>. The <em>dynamic colors</em>
feature allowed those colors to be set via escape
sequences.</p>
</li>
<li>
<p>“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 <em>color_xterm</em>. Raymond's <a href=
"/ncurses/terminfo.src.html#tic-color_xterm">comment</a> in
terminfo.src implies that this program was distributed
earlier; however the copy of <code>color_xterm-alpha4</code>
which I have at hand has file modification dates starting in
December 1995. Wexelblat's commit is an earlier
<em>non-patch</em> use of the feature for xterm.</p>
<p>Both were probably due to Tom Weinstein (also at SGI) in
1992, which you can find in the <a href=
"http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/sources/usr.bin.X11/">
historic Linux</a> archive. The <code>README.color</code>
file in this earlier <a href=
"http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/sources/usr.bin.X11/color_xterm.tar.gz">
color_xterm</a> says</p>
<blockquote>
<pre class="code-block">
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"
</pre>
</blockquote>
<p>Aside from <code>README.color</code>, there was no
documentation. The terminal description was unmodified.</p>
</li>
</ul>
<p>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.</p>
<p id="ANSI_colors_before_and_now">There have been some changes
since the <em>color_xterm</em> in 1992:</p>
<blockquote>
<table border="1" summary="ANSI colors before and now">
<tr>
<th>Resource</th>
<th>1992</th>
<th>1995</th>
<th>2016</th>
</tr>
<tr>
<td><code>color0</code>
</td>
<td><code>Black</code>
</td>
<td><code>black</code>
</td>
<td><code>black</code>
</td>
</tr>
<tr>
<td><code>color1</code>
</td>
<td><code>Red</code>
</td>
<td><code>red3</code>
</td>
<td><code>red3</code>
</td>
</tr>
<tr>
<td><code>color2</code>
</td>
<td><code>Green</code>
</td>
<td><code>green3</code>
</td>
<td><code>green3</code>
</td>
</tr>
<tr>
<td><code>color3</code>
</td>
<td><code>Yellow</code>
</td>
<td><code>yellow3</code>
</td>
<td><code>yellow3</code>
</td>
</tr>
<tr>
<td><code>color4</code>
</td>
<td><code>Blue</code>
</td>
<td><code>blue3</code>
</td>
<td><code>blue2</code>
</td>
</tr>
<tr>
<td><code>color5</code>
</td>
<td><code>Magenta</code>
</td>
<td><code>magenta3</code>
</td>
<td><code>magenta3</code>
</td>
</tr>
<tr>
<td><code>color6</code>
</td>
<td><code>Cyan</code>
</td>
<td><code>cyan3</code>
</td>
<td><code>cyan3</code>
</td>
</tr>
<tr>
<td><code>color7</code>
</td>
<td><code>White</code>
</td>
<td><code>gray90</code>
</td>
<td><code>gray90</code>
</td>
</tr>
<tr>
<td><code>color8</code>
</td>
<td> </td>
<td><code>gray30</code>
</td>
<td><code>gray50</code>
</td>
</tr>
<tr>
<td><code>color9</code>
</td>
<td> </td>
<td><code>red</code>
</td>
<td><code>red</code>
</td>
</tr>
<tr>
<td><code>color10</code>
</td>
<td> </td>
<td><code>green</code>
</td>
<td><code>green</code>
</td>
</tr>
<tr>
<td><code>color11</code>
</td>
<td> </td>
<td><code>yellow</code>
</td>
<td><code>yellow</code>
</td>
</tr>
<tr>
<td><code>color12</code>
</td>
<td> </td>
<td><code>blue</code>
</td>
<td><code>rgb:5c/5c/ff</code>
</td>
</tr>
<tr>
<td><code>color13</code>
</td>
<td> </td>
<td><code>magenta</code>
</td>
<td><code>magenta</code>
</td>
</tr>
<tr>
<td><code>color14</code>
</td>
<td> </td>
<td><code>cyan</code>
</td>
<td><code>cyan</code>
</td>
</tr>
<tr>
<td><code>color15</code>
</td>
<td> </td>
<td><code>white</code>
</td>
<td><code>white</code>
</td>
</tr>
<tr>
<td><code>colorUL</code>
</td>
<td> </td>
<td><code>yellow</code>
</td>
<td><code>foreground</code>
</td>
</tr>
<tr>
<td><code>colorBD</code>
</td>
<td> </td>
<td><code>white</code>
</td>
<td><code>foreground</code>
</td>
</tr>
<tr>
<td><code>colorRV</code>
</td>
<td> </td>
<td> </td>
<td><code>foreground</code>
</td>
</tr>
<tr>
<td><code>colorIT</code>
</td>
<td> </td>
<td> </td>
<td><code>foreground</code>
</td>
</tr>
</table>
</blockquote>
<p>In development of xterm over the past 20 years, we</p>
<ul>
<li>incorporated ANSI (8) colors,</li>
<li>adapted the aixterm feature (16) colors,</li>
<li>added extensions for 88- and 256-colors.</li>
</ul>
<p>Much of that has been adopted by other developers for
different terminal emulators. That is summarized in <a href=
"/ncurses/ncurses.faq.html#xterm_256color">Why not make "xterm"
equated to "xterm-256color"?</a>.</p>
<p>As hinted by the table, the 16-color extension was partly
implemented in xterm by late 1995, using the scheme of Linux
console: <em>bold</em> fonts are shown as <em>brighter</em>
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 <a href=
"/dialog/dialog.html">dialog</a>) there was no reason to pretend
that <a href="#bold_vs_16colors">bold and bright were
synonymous</a>.</p>
<p>The <code>colorUL</code> and <code>colorBD</code> features are
part of this discussion because I incorporated those into the
indexing scheme for colors. More on that later.</p>
<p>First, deal with the 256- and 88-color extensions.</p>
<p>The reason for <em>256</em> colors is that the index would fit
in a byte. Larason's scheme was simple enough:</p>
<ul>
<li>the existing 16 colors</li>
<li>a color cube (6x6x6 is 216, which is the largest cube no
larger than 256).</li>
<li>a grayscale "ramp", using the remaining 24 entries.</li>
</ul>
<p>The xterm source-code includes scripts for demonstrating the
colors, e.g., using the same escape sequences that
<code>tput</code> would use:</p>
<ul>
<li><a href="/xterm/xterm.log.html#xterm_94">patch #94</a>
(1999/03/27) added <code>8colors.sh, 16colors.sh</code></li>
<li><a href="/xterm/xterm.log.html#xterm_111">patch #111</a>
(1999/07/10) added <code>256colors.pl and
256colors2.pl</code></li>
<li><a href="/xterm/xterm.log.html#xterm_115">patch #115</a>
(1999/07/18) added <code>88colors.pl and
88colors2.pl</code></li>
</ul>
<p>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.</p>
<p>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
<em>colormap</em>. 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.</p>
<p id="Allocation_of_colors_for_88/157/256_schemes">The 256- and
88-color schemes (a 16-color table of <em>ANSI</em> (or
<em>aixterm</em>) colors, followed by a cube and then a grayscale
“ramp”) are similar. An intermediate <a href=
"https://lists.gnu.org/archive/html/bug-ncurses/2020-03/msg00025.html">
157-color scheme</a> could have been provided,</p>
<table border="1" summary=
"Allocation of colors for 88/157/256 schemes">
<tr>
<th>88</th>
<th>157</th>
<th>256</th>
<th>Usage</th>
</tr>
<tr>
<td align="right">16</td>
<td align="right">16</td>
<td align="right">16</td>
<td>ANSI/AIX</td>
</tr>
<tr>
<td align="right">64</td>
<td align="right">125</td>
<td align="right">216</td>
<td>cube</td>
</tr>
<tr>
<td align="right">8</td>
<td align="right">16</td>
<td align="right">24</td>
<td>grayscale "ramp"</td>
</tr>
</table>
<p>but the savings in the colormap would be less compelling:</p>
<table border="1" summary=
"Size of colormap for 88/157/256 schemes">
<tr>
<th>Colors</th>
<th>Size</th>
<th>Bits</th>
</tr>
<tr>
<td align="right">88</td>
<td align="right">7744</td>
<td align="right">13</td>
</tr>
<tr>
<td align="right">157</td>
<td align="right">24649</td>
<td align="right">15</td>
</tr>
<tr>
<td align="right">256</td>
<td align="right">65536</td>
<td align="right">16</td>
</tr>
</table>
<p id="semicolon_vs_colon">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:</p>
<ul>
<li>
<p>The default color palette for xterm uses header-files
generated using scripts similar to the ones provided for
demonstrations (<a href=
"/xterm/xterm.log.html#xterm_112">patch #112</a>).</p>
<p>The first 16 colors (except for blue) use names in the X
<code>rgb.txt</code>.</p>
</li>
<li>
<p>The X libraries cannot handle enough resources to specify
all of the 256 colors as well as other features in xterm.</p>
<p>Starting with <a href=
"/xterm/xterm.log.html#xterm_129">patch #129</a>, I made the
<em>resource</em> 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.</p>
</li>
<li>Steve Wall modified the palette in 2002 (<a href=
"/xterm/xterm.log.html#xterm_166">patch #166</a>), making it a
little brighter.</li>
<li>
<p>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.</p>
<p>Using semicolon was incorrect because some applications
could expect their parameters to be order-independent. As
used for the R/G/B values, that <em>was</em> order-dependent.
The relevant information, by the way, is part of ECMA-48 (not
ITU T.416, as mentioned in <a href=
"/ncurses/ncurses.faq.html#xterm_16MegaColors"><em>Why only
16 (or 256) colors?</em></a>). Quoting from <a href=
"https://www.ecma-international.org/publications/files/ECMA-ST/Ecma-048.pdf">
section 5.4.2 of ECMA-48, page 12</a>, and adding emphasis
(not in the standard):</p>
<blockquote>
<p class="code-block">Each parameter sub-string consists of
one or more bit combinations from 03/00 to
<strong>03/10</strong>; the bit combinations from 03/00 to
03/09 represent the digits <em>ZERO</em> to <em>NINE</em>;
bit combination <strong>03/10</strong> may be used as a
separator in a <em>parameter sub-string</em>, for example,
to separate the fractional part of a decimal number from
the integer part of that number.</p>
</blockquote>
<p>and later on page 78, in 8.3.117 <em>SGR – SELECT
GRAPHIC RENDITION</em>, the description of SGR 38:</p>
<blockquote>
<p class="code-block">(reserved for future standardization;
intended for setting character foreground colour as
specified in ISO 8613-6 [CCITT Recommendation T.416])</p>
</blockquote>
<p>Of course you will immediately recognize that
<strong><tt>03/10</tt></strong> is ASCII <em>colon</em>, and
that ISO 8613-6 necessarily refers to the encoding in a
<em>parameter sub-string</em>. Or perhaps you will not.</p>
<p>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.</p>
<p>Later, in 2012 (<a href="/xterm/xterm.log.html">patch
#282</a>), I extended the parser to accommodate the
<em>corrected</em> 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.</p>
<p>On releasing <a href="/ncurses/announce-6.1.html">ncurses
6.1</a> in 2018, I used the corrected syntax in the <a href=
"/ncurses/terminfo.src.html#tic-xterm-direct"><em>xterm-direct</em></a>
terminal description, and also provided working examples for
the other terminals which supported the <em>direct color</em>
feature. Some of those still did not support the standard
syntax for the control sequences:</p>
<ul>
<li><a href=
"/ncurses/terminfo.src.html#tic-xterm_direct">xterm+direct</a>
is the building-block for standard terminals</li>
<li><a href=
"/ncurses/terminfo.src.html#tic-xterm_indirect">xterm+indirect</a>
is a building-block for nonstandard terminals</li>
</ul>
<p>Still later, in 2020, a user's request prompted review of
this area:</p>
<ul>
<li>One of the other terminal developers had implemented a
new feature using xterm's original semicolon
delimiters.</li>
<li>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.</li>
<li>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.</li>
<li>The feature itself is nonstandard, using a code marked
in ECMA-48 for future standardization, so there is no
reason to modify xterm.</li>
<li>As noted in the ncurses FAQ <a href=
"/ncurses/ncurses.faq.html#xterm_generic"><em>Why not just
use TERM set to "xterm"?</em></a>, sometimes xterm's
terminal description uses features not supported by other
terminals.</li>
<li>ncurses has correct terminal descriptions for xterm and
other terminals (such as the one with the nonstandard
feature).</li>
<li>Providing a terminal description using the nonstandard
semicolon for delimiting subparameters encourages users to
stumble into this problem.</li>
<li>Going forward (e.g., xterm patch #357), these terminfo
building blocks are used in ncurses:
<ul>
<li><a href=
"/ncurses/terminfo.src.html#tic-xterm_256color2">xterm+256color<strong>2</strong></a>
is the building-block for standard terminals</li>
<li><a href=
"/ncurses/terminfo.src.html#tic-xterm_256color">xterm+256color</a>
is a building-block for nonstandard terminals</li>
</ul>
</li>
</ul>
</li>
</ul>
<p id="changing_256color_palette">As others incorporated the
xterm 256-color feature, the ability to <em>set</em> 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-<em>compatible</em> implementation
with support for 256-colors automatically supports 88-colors,
since the palette is modifiable, which makes comments such as
<a href=
"http://unix.stackexchange.com/questions/269077/tput-setaf-color-table-how-to-determine-color-codes">
this</a> at best badly informed.</p>
<p>A few non-xterm applications may support the feature,
e.g.,</p>
<ul>
<li><a href="/ncurses/terminfo.src.html#tic-putty">PuTTY</a>
(Windows)</li>
<li><a href="/ncurses/terminfo.src.html#tic-iterm2">iTerm2</a>
(MacOS)</li>
<li><a href="/ncurses/terminfo.src.html#tic-teken">teken</a>
(FreeBSD)</li>
</ul>
<p>though the results may not be satisfactory. Here are
screenshots for 88- and 256-colors which I made in <a href=
"https://lists.freebsd.org/pipermail/freebsd-arch/2014-February/015081.html">
February 2014</a> while discussing deficiencies of the FreeBSD
console emulator:</p>
<blockquote>
<p><a href="/xterm/images/teken-88colors.png"><img width="450"
src="images/teken-88colors.png" alt="teken with 88-colors"></a></p>
<p><a href="/xterm/images/teken-256colors.png"><img width="450"
src="images/teken-256colors.png" alt=
"teken with 256-colors"></a></p>
</blockquote>
<p>XTerm stores the colors for <code>colorUL</code>, etc., at the
end of the color array used for ANSI, 16-, 88- and 256-colors. An
application can <em>modify</em> the colors using
<code>OSC 4</code>, which does not reduce the range
available for the <code>SGR 38/48</code> index used for
<em>selecting</em> 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. <a href="http://olesenm.github.io/about/">Mark
J Olesen</a> 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 <a href=
"https://lists.gnu.org/archive/html/groff/2001-10/msg00055.html">in
2001</a> to color manpages, this feature is not that well
known.</p>
<p>Finally, there are the <em>default</em> foreground and
background colors set using <code>SGR 39/49</code>.</p>
<p>If one wants to enumerate the colors which can be set by index
in xterm, there are multiple indices that are needed:</p>
<ul>
<li>SGR number (for the 8 ANSI colors, the extra 8 aixterm
colors and the default colors)</li>
<li>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)</li>
<li>OSC 4 with (index) parameter (colored video
attributes)</li>
<li>OSC numbers 10-19 (dynamic colors)</li>
</ul>
<p>The sample scripts in xterm's sources demonstrate these
features. Some are written in POSIX shell, the remainder are in
Perl.</p>
<h4 id="dont_like_blue-id"><a name="dont_like_blue" id=
"dont_like_blue">I don't like that shade of blue</a></h4>
<p>Nobody does. But there are no universal solutions.</p>
<p>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.</p>
<p>The available standards do not help: there <em>are</em> no
standards for terminal colors. Here is an illustration which I
made in reply to a <a href=
"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=241717">bug
report</a>, contrasting different choices for blue, against some
of the other terminals which (were said to) provide "standard
vt100 colors":</p>
<blockquote class="code-block">
<p><a href="/xterm/images/contrast.jpg"><img width="450" src=
"images/contrast.jpg" alt=
"Contrasting blue in terminal emulators"></a></p>
</blockquote>
<p>Of course, anyone <em>developing</em> a terminal emulator
already knew that <a href=
"/ncurses/ncurses.faq.html#vt100_color">vt100's never did do
colors</a>.</p>
<p>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.</p>
<h4 id="why_no_italics-id"><a name="why_no_italics" id=
"why_no_italics">Why doesn't xterm support italics?</a></h4>
<p>Well, actually it does and it doesn't.</p>
<p>You can display "any" font using xterm (though proportional
fonts may be disappointing).</p>
<p>But xterm has specific types of graphic rendition that it will
do. If you want italics, then xterm has an option
(<code>italicULMode</code>) to use that rendition instead of
underlining. That is the usual typographic alternative, though of
course some people want both at the same time.</p>
<p>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 <a href="/ncurses/NEWS.html#t20130831">partial
support</a>, but programs using this feature will not work with
other implementations).</p>
<p>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:</p>
<table border="1" summary="Bits for XTerm's graphic rendition">
<tr>
<th>Mnemonic</th>
<th>Bit</th>
<th>Description</th>
</tr>
<tr>
<td>INVERSE</td>
<td>0</td>
<td>show cell reverse-video</td>
</tr>
<tr>
<td>UNDERLINE</td>
<td>1</td>
<td>show cell underlined</td>
</tr>
<tr>
<td>BOLD</td>
<td>2</td>
<td>show cell as bold</td>
</tr>
<tr>
<td>BLINK</td>
<td>3</td>
<td>show cell as blinking</td>
</tr>
<tr>
<td>BG_COLOR</td>
<td>4</td>
<td>use background color</td>
</tr>
<tr>
<td>FG_COLOR</td>
<td>5</td>
<td>use foreground color</td>
</tr>
<tr>
<td>PROTECTED</td>
<td>6</td>
<td>character cannot be erased</td>
</tr>
<tr>
<td>CHARDRAWN</td>
<td>7</td>
<td>character has been drawn here on the screen</td>
</tr>
</table>
<p>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.</p>
<p>For those who are not constrained by cost, since <a href=
"xterm.log.html#xterm_305">patch #305</a> 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 <a href=
"/ncurses/NEWS.html#t20130831">5.9.20130831</a>):</p>
<ul>
<li>this increases the size of the attributes data.</li>
<li>the feature requires some overhead for font-switching
(treating italics as "rare")</li>
</ul>
<p>The increase in size is not entirely wasted. The SGR
attributes for <em>dim</em>, <em>strike-out</em>, and
<em>double-underscore</em> 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 <code>A_STRIKE</code> for that
reason).</p>
<p>Here are screenshots showing the ncurses test-program
displaying video attributes (including italics). The first uses
bitmap fonts:</p>
<blockquote>
<p><a href=
"/ncurses/images/ncurses6-bitmap-italics.png"><img width="300"
src="/ncurses/images/ncurses6-bitmap-italics.png" alt=
"ncurses – video attributes with bitmap-font"></a></p>
</blockquote>
<p>and the second uses a (same size) TrueType font:</p>
<blockquote>
<p><a href=
"/ncurses/images/ncurses6-truetype-italics.png"><img width=
"300" src="/ncurses/images/ncurses6-truetype-italics.png" alt=
"ncurses – video attributes with TrueType font"></a></p>
</blockquote>
<h4 id="grep_colors-id"><a name="grep_colors" id=
"grep_colors">"grep --color" does not show the right output</a></h4>
<p>GNU grep (version 2.5) introduced a <code>--color</code>
option.</p>
<p>It does this for each highlighted match:</p>
<ol>
<li>it writes the text up to (not including the match)</li>
<li>it writes an ANSI color control control sequence</li>
<li>it writes the matched text</li>
<li>it writes a control sequence to clear to the end of the
line</li>
<li>it writes an ANSI control sequence to reset graphic
rendition.</li>
<li>repeat this process until the entire line is written.</li>
</ol>
<p>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.</p>
<p>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 (<a href="/vttest/vttest.html">vttest</a>
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.</p>
<p>Here are some relevant bug reports:</p>
<ul>
<li><a href=
"https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=456943">Debian
#456943 - grep: incorrect display with color and wrapping in
some terminals</a></li>
<li><a href=
"https://bugzilla.redhat.com/show_bug.cgi?id=1006310">Fedora
#1006310 - xterm does not print a character if the character is
last on a row and a color-change ANSI sequence follows</a></li>
<li><a href=
"https://bugzilla.novell.com/show_bug.cgi?id=148844">Novell
#148844 - terminal text wrapping bug</a></li>
</ul>
<h4 id="vt100_wrapping-id"><a name="vt100_wrapping" id=
"vt100_wrapping">That description of wrapping is odd, say
more?</a></h4>
<p>This is one of the aspects of the so-called "vt100 glitch", as
mentioned in the terminfo manpage:</p>
<blockquote class="code-block">
<p>Terminals which ignore a line-feed immediately after an am
wrap, such as the Concept and vt100, should indicate xenl.</p>
</blockquote>
<p>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.</p>
<p>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).</p>
<p><a href="/vttest/CHANGES">In 2004</a>, 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.</p>
<p>Reviewing the results with xterm-alikes or less ambitious
"vt100 emulators" in mid-2013:</p>
<ul>
<li>
<p>xterm, kterm, mlterm, some operating system consoles are
consistent with the VT100 behavior.</p>
</li>
<li>
<p>rxvt, screen, putty (pterm), konsole, vte (gnome-terminal,
xfce4-terminal) are not consistent with VT100 (and behave
differently compared to each other).</p>
<p>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.</p>
</li>
<li>mrxvt does not get to that screen; it resizes its window to
a single line.</li>
</ul>
<p>In the <a href="/vttest/vttest-wrap.html">vttest</a> page, I
have provided screenshots to illustrate these points.</p>
<p>Since 2013, Mattias Engdegård created a test program to
explore this area, citing DEC's internal standard document for
terminals (<a href=
"http://www.bitsavers.org/pdf/dec/standards/EL-SM070-00_DEC_STD_070_Video_Systems_Reference_Manual_Dec91.pdf"><em>DEC
STD 070 Video Systems Reference Manual</em></a>). That document
refers to this as the <em>last column flag</em>.</p>
<p>Revisiting this in 2019, no improvement has been observed in
the problematic programs from 2013. A VTE user gave this
example</p>
<blockquote>
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="comment">#!/bin/bash</span><br>
<strong><span class=
"keyword">echo</span></strong> -e <span class=
"literal">"</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">e[2J"</span><br>
<strong><span class=
"keyword">echo</span></strong> -e <span class=
"literal">"</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">e[1;79Hx</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">b</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">vx</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">b</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">vx</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">n"</span><br>
<strong><span class=
"keyword">echo</span></strong> -e <span class=
"literal">"</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">e[5;80Hx</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">b</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">vx</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">b</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">vx</span><strong><em><span class=
"keyword2">\</span></em></strong><span class=
"literal">n"</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>In this case, DEC's documentation for the <em>last column
flag</em> mentions that cursor-positioning resets the flag.
Because <strong>xterm</strong> 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., <strong>xterm</strong>, <em>zoc</em>, MacOS
<em>Terminal</em>, <em>st</em>) implement this detail in the same
way that the hardware terminal did:</p>
<blockquote>
<p><a href="images/LCF-versus-CUP.jpg"><img width="200" src=
"images/LCF-versus-CUP.jpg" alt=
"screenshot of last column flag with cursor positioning"></a></p>
</blockquote>
<h4><a id="bce_oddness" name="bce_oddness">That color scheme is
odd, say more?</a></h4>
<p>Occasionally someone questions the behavior of the
<strong>bce</strong> (<em>background color erase</em>) feature in
<strong>xterm</strong>, and mentions that some DEC terminal did
not behave that way with ANSI colors.</p>
<p>First off:</p>
<ul>
<li>
<p>Aside from the VT525, DEC terminals had no support for
ANSI colors.</p>
</li>
<li>
<p>Likely, they were thinking of a terminal <em>emulator</em>
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.</p>
<p>Some developers were aware of this, others were not. The
<em>comp.os.vms</em> newsgroup thread <a href=
"https://groups.google.com/forum/#!topic/comp.os.vms/U0kbnWP4dMU">
<em>How to setting color in code for a VT terminal</em></a>
shows both.</p>
</li>
<li>
<p>From the outset, <em>modern xterm</em> was a VT100 or
VT220 <em>with</em> 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.</p>
</li>
</ul>
<p>The design used for <strong>xterm</strong> imitated Linux
console, which itself came about from different people (see
<a href="/ncurses/ncurses-slang.html#cause_bce">this page</a> for
some background).</p>
<p>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 <em>bce</em>: any <em>erase</em> 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.</p>
<h3 id="problems_weird-id"><a name="problems_weird" id=
"problems_weird">Odd behavior</a></h3>
<h4 id="xterm_paste-id"><a name="xterm_paste" id=
"xterm_paste">Why can't I select/paste in xterm?</a></h4>
<p>When an application sets xterm to any of its <a href=
"ctlseqs/ctlseqs.html#h2-Mouse-Tracking">mouse tracking
modes</a>, it reserves the <em>unshifted</em> 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
<em>shift</em> key while clicking with the mouse.</p>
<p>This is all done using the <em>translations</em> resource (see
the <a href=
"manpage/xterm.html#h3-Default-Key-Bindings"><em>Default Key
Bindings</em></a> section in the manual page).</p>
<h4><a name="xterm_select_clipboard" id=
"xterm_select_clipboard">Why can't I select/paste to/from other
programs?</a></h4>
<p>Whether you select text in xterm and paste into another
window, or the reverse, the X client in which you have
<em>selected</em> text may provide the data in different
<em>formats</em> and different <em>containers</em>:</p>
<blockquote>
<dl>
<dt><em>formats</em>
</dt>
<dd>
<p>Originally (and by default) xterm made the selected data
available with ISO-8859-1 encoding (Latin-1). Since
<a href="xterm.log.html#xterm_101">patch #101 (1999)</a>,
it has provided it also in UTF-8.</p>
<p>Regarding the type of data:</p>
<ul>
<li>X11R4's ICCM documented "string" selection data with
ISO-8859-1, while</li>
<li>X11R6 documented "compound text" (another name for
multibyte encoding, without specifying <em>what</em>
encoding).</li>
<li>Selection data using UTF-8 was an extension by
XFree86.</li>
</ul>
<p>The client holding the selection advertises the formats
that it can provide, and other client(s) ask for it using
one of those formats.</p>
<p>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.</p>
</dd>
<dt><em>containers</em>
</dt>
<dd>
<p>By default, xterm follows the <a href=
"https://tronche.com/gui/x/icccm/"><em>Inter-Client
Communication Conventions Manual</em></a> (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.</p>
<p>The ICCM specifies <a href=
"https://tronche.com/gui/x/icccm/sec-2.html#s-2.6"><em>"selection
atoms"</em></a> which are maintained by the X server.
According to the ICCM:</p>
<blockquote>
<p>The selection named by the atom <em>PRIMARY</em> 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.</p>
</blockquote>
<p>and</p>
<blockquote>
<p>The selection named by the atom <em>CLIPBOARD</em> is
used to hold data that is being transferred between
clients, that is, data that usually is being cut or
copied, and then pasted.</p>
</blockquote>
<p>xterm uses PRIMARY by default. The default translations
also update something called CUT_BUFFER0 (also <a href=
"https://tronche.com/gui/x/icccm/sec-3.html#s-3">part of
the ICCM</a>).</p>
<p>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 <em>persistent</em>, while the
PRIMARY selection is <em>not</em>. An X client can provide
data using the PRIMARY selection only as long as it
<em>holds</em> the selection.</p>
</dd>
</dl>
</blockquote>
<p>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
<code>keepSelection</code> resource in <a href=
"xterm.log.html#xterm_230">patch #230</a> (2007), as well as
refinements to retain highlighting when it updates other parts of
the window.</p>
<p>A more likely reason for failing to select/paste is that the
other application may not use the same <em>selection atom</em>
(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").</p>
<p>Not all applications followed Netscape and its descendents,
making it a nuisance if one wanted to select/paste text to/from
the web browser.</p>
<p>Since <a href="xterm.log.html#xterm_209">patch #209</a>
(2006), xterm has provided a workaround: a menu entry (and
resource <code>selectToClipboard</code>) which changes xterm's
behavior for a special token <em>SELECT</em> in its default
translations. If the resource is true (or the menu item enabled),
xterm provides its selection to the <em>CLIPBOARD</em>. A menu
item is provided, of course, since many applications follow the
ICCM. In the default translations, these lines use
<em>SELECT</em>:</p>
<blockquote>
<pre class="code-block">
Shift <KeyPress> Select:select-cursor-start() \
select-cursor-end(SELECT, CUT_BUFFER0) \n\
Shift <KeyPress> Insert:insert-selection(SELECT, CUT_BUFFER0) \n\
</pre>
</blockquote>
<h4 id="xterm_tabs-id"><a name="xterm_tabs" id="xterm_tabs">Why
can't I select tabs in xterm?</a></h4>
<p>This issue was noted early on, <a href=
"xterm.faq.html#known_bugs">here</a> in 1997.</p>
<p><strong>XTerm</strong> 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.</p>
<p>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.</p>
<p>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).</p>
<p>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.</p>
<p>For the special case where your expectations would match the
available data, it is solvable. There are basically two ways it
could be done:</p>
<ul>
<li>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.</li>
<li>store literal tabs and nulls to be interpreted later
– both by the display and the selection logic.</li>
</ul>
<p>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).</p>
<h4><a name="xterm_paste_nl" id="xterm_paste_nl">Can
bracketed-paste solve my problems?</a></h4>
<p>That depends. Bracketed-paste only gives an application a
<em>clue</em> that the input from the keyboard is being pasted
rather than typed. It was intended to help with the
<em>autoindent</em> feature in text editors. But not all programs
recognize the feature (see <a href="xterm-paste64.html">this
page</a> for more information).</p>
<h4 id="xterm_resize-id"><a name="xterm_resize" id=
"xterm_resize">FVWM does weird things when I try to resize
xterm</a></h4>
<p>I have an old (3.1.2G) bug report for xterm which may be
related to the second (3.9s) problem:</p>
<ul>
<li>Steven Lang <tiger@ecis.com> reports a problem with
extra resize events for xterm.
<p>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.</p>
<p>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.</p>
</li>
<li>Stephen Marley <stephen@memex.com> reports a problem
with the active icon (from X11R6.3 xterm):
<p>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.</p>
<p>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.</p>
<p>The xterm now shrinks to a tiny size and attempts to
resize it result in it shrinking again.</p>
<p>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.</p>
</li>
</ul>
<p>I have not observed the first, but have reproduced the
second.</p>
<h4 id="xterm_tite-id"><a name="xterm_tite" id="xterm_tite">Why
doesn't the screen clear when running vi?</a></h4>
<p>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.</p>
<p>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.</p>
<p>Under SunOS 4.x, the termcap description for xterm embeds in
the <code>ti</code> and <code>te</code> capabilities a command to
switch to xterm's alternate screen (e.g., while running
<code>vi</code>), and return to the normal screen on exit. This
has the effect of clearing the screen. The corresponding terminfo
symbols for <code>ti</code> and <code>te</code> are
<code>smcup</code> and <code>rmcup</code>, respectively.</p>
<p>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
<code>smcup</code> and <code>rmcup</code> capabilities. However,
Sun began distributing modern xterm on the <em>freeware
companion</em> (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.</p>
<p>Because it is in the terminal description, the feature is
configurable...</p>
<p>For example (from Bjorn Helgaas <helgaas@dhc.net>) this
procedure adds these capabilities to the "xterm" terminfo
definition on HP-UX 10.20:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
cp /usr/lib/terminfo/x/xterm /usr/lib/terminfo/x/xterm.orig<br>
untic xterm > /tmp/xterm.src<br>
<span class="keyword">echo</span> <span class=
"literal">" smcup=</span><span class=
"keyword2">\</span><span class="literal">E7</span><span class=
"keyword2">\</span><span class=
"literal">E[?47h, rmcup=</span><span class=
"keyword2">\</span><span class=
"literal">E[2J</span><span class="keyword2">\</span><span class="literal">E[?47l</span><span class="keyword2">\</span><span class="literal">E8,"</span> >> /tmp/xterm.src<br>
tic /tmp/xterm.src<br>
<!--atr2html}}--></p>
</blockquote>
<p>In this example, the terminfo strings are a series of
operations:</p>
<blockquote>
<dl>
<dt><code>smcup</code>
</dt>
<dd><code>\E7</code> saves the cursor's position</dd>
<dd><code>\E[?47h</code> switches to the alternate
screen</dd>
<dt><code>rmcup</code>
</dt>
<dd><code>\E[2J</code> clears the screen (assumed to be the
alternate screen)</dd>
<dd><code>\E[?47l</code> switches back to the normal
screen</dd>
<dd><code>\E8</code> restores the cursor's position.</dd>
</dl>
</blockquote>
<p>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 <code>titeInhibit</code> which
manipulates the $TERMCAP variable to accomplish this. It sets the
$TERMCAP variable for the client with the <code>ti</code> and
<code>te</code> 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
<code>titeInhibit</code>, but not the associated cursor
save/restore and clear-screen operations.</p>
<p><a href="/xterm/xterm.log.html#xterm_54">XFree86 3.9s</a>
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 <code>ti</code> sequence (save cursor,
switch to alternate screen, clear screen) and <code>te</code>
(switch to normal screen, restore cursor) as two control
sequences that can be disabled by <code>titeInhibit</code>.</p>
<p>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 <a href=
"xterm.log.html#xterm_90">patch #90 in 1998</a> 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 <code>titeInhibit</code> resource using another popup
menu entry (<code>Enable Alternate Screen Switching</code>).</p>
<p>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.</p>
<h4 id="xterm_form_feed-id"><a name="xterm_form_feed" id=
"xterm_form_feed">Why doesn't the screen clear when I type
control/L?</a></h4>
<p><em>Control/L</em> is ASCII <em>form-feed</em>. Printers do
something with form-feed. Terminals do not, as a rule (though I
agree it would be nice, e.g., <a href=
"/personal/oldprogs.html#repaginator">this</a>).</p>
<p>Interpreting form-feed is normally done by your shell, not by
the terminal emulator. In a quick check:</p>
<ul>
<li>bash, tcsh, zsh interpret form-feed by clearing the screen,
while</li>
<li>csh, dash, ksh, mksh, yash do not</li>
</ul>
<p>VT100s did not respond to form-feed. A few terminal emulators
interpret form-feed (PuTTY and SunOS console), but neither
matches VT100 behavior.</p>
<p>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. <a href=
"http://www.thecodingforums.com/threads/screen-editing.444014/page-2#post-2480220">
Several years ago</a>, I pointed this out as one of the errors in
the <a href="http://c-faq.com/osdep/termcap.html">C FAQ</a>
(notwithstanding Summit's comment, he did not update the
FAQ).</p>
<h4 id="xterm_vite-id"><a name="xterm_vite" id="xterm_vite">Why
is the cursor misplaced after running vi?</a></h4>
<p>Vi and other full-screen applications use the termcap
<code>ti/te</code> (terminfo <code>smcup/rmcup</code>) strings to
initiate and end cursor addressing mode. As mentioned in the
discussion of <a href=
"xterm.faq.html#xterm_tite">titeInhibit</a>, full-screen
applications can expect the initialization string to save the
cursor's position, and the end-string to restore it.</p>
<p>A few applications (reportedly IRIX 5.x and 6.x
<code>vi</code> 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).</p>
<p>The usual reason is due to the cursor save/restore controls in
the <code>ti/te</code> 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, <a href=
"xterm.log.html#xterm_90">patch 90</a>) 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.</p>
<h4 id="narrowproto-id"><a name="narrowproto" id=
"narrowproto">Why doesn't the scrollbar work?</a></h4>
<p>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.</p>
<p>For instance</p>
<blockquote>
<pre class="code-block">
configure --disable-imake --disable-narrowproto
</pre>
</blockquote>
<h4 id="xaw_scrollbars-id"><a name="xaw_scrollbars" id=
"xaw_scrollbars">Can I improve the scrollbars?</a></h4>
<p>Is that a problem with the appearance, or the way they
work?</p>
<p>The appearance can be modified (though few do this) by linking
with one of the variants of the Athena widget set (Xaw).</p>
<p>To illustrate, here are a few screenshots:</p>
<blockquote>
<dl>
<dt>Xaw (default)</dt>
<dd>
<p><a href="images/xterm-Xaw.png"><img width="300" src=
"images/xterm-Xaw.png" alt=
"xterm – default scrollbar with Xaw"></a></p>
</dd>
<dt>XawPlus</dt>
<dd>
<p><a href="images/xterm-XawPlus.png"><img width="300" src=
"images/xterm-XawPlus.png" alt=
"xterm – scrollbar with XawPlus"></a></p>
</dd>
<dt>Xaw3d</dt>
<dd>
<p><a href="images/xterm-Xaw3d.png"><img width="300" src=
"images/xterm-Xaw3d.png" alt=
"xterm – scrollbar with Xaw3d"></a></p>
</dd>
<dt>neXtaw</dt>
<dd>
<p><a href="images/xterm-neXtaw.png"><img width="300" src=
"images/xterm-neXtaw.png" alt=
"xterm – scrollbar with neXtaw"></a></p>
</dd>
</dl>
</blockquote>
<p>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 <a href=
"#bug_mxterm">mxterm</a>), 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.</p>
<h4 id="scroll_speed-id"><a name="scroll_speed" id=
"scroll_speed">Can I improve the scrolling speed?</a></h4>
<p>Several years ago (before 2010) there was a <a href=
"https://web.archive.org/web/20091210162250/https://martin.ankerl.com/2007/09/01/comprehensive-linux-terminal-performance-comparison/">
webpage</a> which gave its author's notion of what constituted a
“good” terminal emulator:
<strong><code>cat</code></strong>'ing (sending) a large file to
the terminal would complete in minimal time. Apparently that was
the sole interest. Interestingly, its author stated that
<em>xterm</em> 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
<strong><em>Windows</em></strong>. The page spawned a few
imitators (with no better methodology), none was systematic, none
did any analysis.</p>
<p>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.</p>
<p>There is more than one factor involved in scrolling speed.
Here are a few:</p>
<ul>
<li>
<p>When <strong>xterm</strong> was first written, machines
had less memory, and scrolling back a thousand lines seemed
good enough for users. Internally, <em>xterm</em> 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.</p>
<p>But the <a href=
"manpage/xterm.html#VT100-Widget-Resources:saveLines"><code>saveLines</code></a>
resource allows a full <em>integer</em>, and during the
mid/late-1990s, a few users found that setting the resource
to a million lines made <em>xterm</em> very slow.</p>
<p>Still, the graphics display was fast enough. By the way,
<em>xterm</em> uses the <em>XCopyArea</em> function, and
normally (attempts to) display all of the updates to the
screen.</p>
</li>
<li>
<p>Later, <strong>rxvt</strong> 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
<em>XCopyArea</em>, noting in its features</p>
<blockquote>
<pre class="code-block">
/*
* Define to remove support for XCopyArea() support. XCopyArea() is useful
* for scrolling on non-local X displays
*/
/* #define NO_SLOW_LINK_SUPPORT */
</pre>
</blockquote>
<p>Unlike <em>xterm</em>, <em>rxvt</em> 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.</p>
</li>
<li>
<p>A few other terminal emulators, such as
<strong>konsole</strong> copied the <em>rxvt</em> 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.</p>
</li>
<li>
<p>The issue with <em>xterm</em> shifting a large array was a
problem which was addressed by changing all of the pointers
to its line data into a <a href=
"http://www.geeksforgeeks.org/implementation-deque-using-circular-array/">
<em>circular array</em></a> in 2009 (<a href=
"xterm.log.html#xterm_244">patch #244</a>).</p>
</li>
<li>
<p>Even after improving the memory performance of scrolling,
<em>rxvt</em> and its imitators still appeared to scroll
faster.</p>
<p>The <a href=
"manpage/xterm.html#VT100-Widget-Resources:fastScroll"><code>fastScroll</code></a>
resource added in patch #244 provides a simple implementation
of the <em>rxvt</em> (mis?)feature for <em>xterm</em>.</p>
<p>As implemented, it is rather crude (sometimes
<em>xterm</em> — like <em>konsole</em> — appears
to stop, since it is waiting for a new set of screen updates
after having discarded some).</p>
</li>
</ul>
<p>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.</p>
<p>For example, running the <strong>dots</strong> program from
the <a href="/ncurses/ncurses-examples.html">ncurses-examples</a>
shows some interesting misbehavior with <em>gnome-terminal</em>
and <em>konsole</em>: both “choke” at times for a few
seconds. The <em>dots</em> program prints colored cells randomly
around the screen, pausing briefly 1% of the time. However when
<em>dots</em> 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
<em>dots</em>; one possible explanation for the discrepancy is
that the terminal emulator discards output (as in the special
case of scrolling).</p>
<p>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 <em>ncurses</em>'s <a href=
"/ncurses/terminfo.src.html"><code>terminfo.src</code></a>
(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:</p>
<table border="1" summary="examples of scrolling speed">
<tr>
<th rowspan="2" style="width:6em;">Mode</th>
<th rowspan="2" style="width:10em;">Terminal</th>
<th colspan="3">Fedora</th>
<th colspan="3">Ubuntu</th>
</tr>
<tr>
<th style="width:4em;">1</th>
<th style="width:4em;">10</th>
<th style="width:4em;">99</th>
<th style="width:4em;">1</th>
<th style="width:4em;">10</th>
<th style="width:4em;">99</th>
</tr>
<tr>
<td rowspan="10" align="center">Remote</td>
<td>gnome-terminal</td>
<td>(1)</td>
<td>(1)</td>
<td>(1)</td>
<td>(1)</td>
<td>(1)</td>
<td>(1)</td>
</tr>
<tr>
<td>konsole</td>
<td>0.12</td>
<td>2.10</td>
<td>23.2</td>
<td>0.26</td>
<td>2.65</td>
<td>25.7</td>
</tr>
<tr>
<td>mlterm</td>
<td>(2)</td>
<td>(2)</td>
<td>(2)</td>
<td>0.30</td>
<td>3.07</td>
<td>30.4</td>
</tr>
<tr>
<td>pterm / putty</td>
<td>0.15</td>
<td>1.42</td>
<td>14.6</td>
<td>0.55</td>
<td>5.66</td>
<td>56.2</td>
</tr>
<tr>
<td>rxvt (3)</td>
<td>0.25</td>
<td>2.97</td>
<td>29.5</td>
<td>0.23</td>
<td>3.03</td>
<td>29.5</td>
</tr>
<tr>
<td>st / stterm (4)</td>
<td>0.07</td>
<td>0.50</td>
<td>4.40</td>
<td>0.15</td>
<td>1.42</td>
<td>14.4</td>
</tr>
<tr>
<td>terminology</td>
<td>0.10</td>
<td>1.00</td>
<td>10.1</td>
<td>0.19</td>
<td>2.01</td>
<td>19.0</td>
</tr>
<tr>
<td>urxvt</td>
<td>0.05</td>
<td>0.38</td>
<td>3.24</td>
<td>0.17</td>
<td>1.60</td>
<td>15.7</td>
</tr>
<tr>
<td>xterm</td>
<td>0.31</td>
<td>3.50</td>
<td>34.8</td>
<td>0.47</td>
<td>4.41</td>
<td>44.1</td>
</tr>
<tr>
<td>xterm + fastScroll</td>
<td>0.09</td>
<td>0.82</td>
<td>8.36</td>
<td>0.39</td>
<td>2.43</td>
<td>22.9</td>
</tr>
<tr>
<td rowspan="10" align="center">Local</td>
<td>gnome-terminal</td>
<td>0.12</td>
<td>1.16</td>
<td>11.4</td>
<td>0.29</td>
<td>3.14</td>
<td>30.6</td>
</tr>
<tr>
<td>konsole</td>
<td>0.11</td>
<td>0.82</td>
<td>7.97</td>
<td>0.22</td>
<td>2.17</td>
<td>20.1</td>
</tr>
<tr>
<td>mlterm</td>
<td>(2)</td>
<td>(2)</td>
<td>(2)</td>
<td>1.01</td>
<td>7.59</td>
<td>105.</td>
</tr>
<tr>
<td>pterm / putty</td>
<td>0.17</td>
<td>1.52</td>
<td>14.6</td>
<td>(5)</td>
<td>(5)</td>
<td>(5)</td>
</tr>
<tr>
<td>rxvt</td>
<td>1.23</td>
<td>11.9</td>
<td>118.</td>
<td>1.75</td>
<td>16.9</td>
<td>166.</td>
</tr>
<tr>
<td>st / stterm (4)</td>
<td>0.08</td>
<td>0.61</td>
<td>5.10</td>
<td>0.21</td>
<td>1.63</td>
<td>15.9</td>
</tr>
<tr>
<td>terminology</td>
<td>0.09</td>
<td>1.03</td>
<td>10.1</td>
<td>0.43</td>
<td>1.64</td>
<td>16.0</td>
</tr>
<tr>
<td>urxvt</td>
<td>0.07</td>
<td>0.53</td>
<td>4.52</td>
<td>0.26</td>
<td>2.41</td>
<td>23.7</td>
</tr>
<tr>
<td>xterm</td>
<td>1.77</td>
<td>18.5</td>
<td>178.</td>
<td>2.70</td>
<td>26.5</td>
<td>259.</td>
</tr>
<tr>
<td>xterm + fastScroll</td>
<td>0.12</td>
<td>0.96</td>
<td>9.92</td>
<td>0.25</td>
<td>2.36</td>
<td>22.9</td>
</tr>
</table>
<p><strong>Notes</strong>:</p>
<ol>
<li>
<p>On both systems, <em>gnome-terminal</em> failed to connect
remotely.</p>
</li>
<li>
<p>Fedora does not have <em>mlterm</em>.</p>
</li>
<li>
<p>On Ubuntu, the <em>urxvt</em> package hijacks the name
“rxvt”, so the <em>“rxvt”</em>
actually tested was <em>rxvt-xpm</em> from the rxvt 2.7.10
package.</p>
</li>
<li>
<p>Fedora has <em>st</em> 0.70, while Ubuntu has version
0.60, which is a couple of years older.</p>
</li>
<li>
<p>Running locally on Ubuntu, <em>pterm</em> 0.70-1 dumped
core.</p>
</li>
</ol>
<p>Regarding the selection of terminal emulators:</p>
<ul>
<li>
<p>Keeping mind that this is an <em>xterm</em> FAQ, the Linux
console (and Windows console, and PuTTY running on Windows)
are off-topic.</p>
</li>
<li>
<p>The table mentions programs which at one time or another
have set <a href=
"/ncurses/ncurses.faq.html#xterm_generic"><code>TERM=xterm</code></a>.</p>
<p>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.</p>
</li>
<li>
<p>Given that, <em>rxvt</em> 2.7.10 is listed, as well as its
descendent <em>urxvt</em> (rxvt-unicode).</p>
<p>Other variations of <em>rxvt</em> (such as <em>aterm</em>
and <em>mrxvt</em>) were considered, but since much of the
related code is identical, not very interesting.</p>
</li>
<li>
<p>Both systems have several variants of the <em>skins</em>
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.</p>
</li>
<li>
<p>The Unix port of PuTTY, <em>pterm</em> is listed. It uses
<em>GDK</em>.</p>
</li>
</ul>
<p>Interestingly, performance is better running remotely. In the
test, the machines are not identical:</p>
<ul>
<li>The <em>remote</em> system uses a Mac mini-server.</li>
<li>The Fedora system is a virtual machine using
Parallels.</li>
<li>The Ubuntu system is a virtual machine using Vmware
Fusion.</li>
</ul>
<p>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.</p>
<ul>
<li>
<p>For a while, <em>XCopyArea</em> was a problem, where the
Xorg hackers had degraded its performance radically. While
that might still be the underlying issue, <em>st</em> and
<em>urxvt</em> do use that function.</p>
</li>
<li>
<p>Another possibility is mentioned in <em><a href=
"#compiz_bugs">Why is the text in the wrong place?</a></em>
where the apparent root cause was a server feature which only
implemented parts of the X protocol.</p>
</li>
</ul>
<p>Using the <em>fastScroll</em> feature made <em>xterm</em>
performance comparable to the “desktop” applications.
But as usual, with performance data, your mileage may vary.</p>
<h4 id="window_ops-id"><a name="window_ops" id="window_ops">Why
can't my program read the window title?</a></h4>
<p>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.</p>
<p><strong>XTerm</strong> provides resource-settings and menu
entries to allow this and related features to be enabled or
disabled. See for example <code>allowWindowOps</code> The default
resource settings in xterm can be overridden by a packager.
However, a knowledgable user can override those default
settings.</p>
<p>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).</p>
<p>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 <code>resize</code> 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.</p>
<h4 id="window_ops2-id"><a name="window_ops2" id=
"window_ops2">Why can't my program set the window size?</a></h4>
<p>Some overzealous packagers, perhaps influenced by the
demonstration I provided, are protecting you against the
possibility of your xterm becoming inaccessible. (That's
unlikely...).</p>
<p>You should be able to override it, as noted above via resource
settings or menu entry ("Allow Window Ops").</p>
<h4><a name="compiz_bugs" id="compiz_bugs">Why is the text in the
wrong place?</a></h4>
<p>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.</p>
<p>There ware several related symptoms, e.g.,</p>
<ul>
<li>text may be the wrong size</li>
<li>repainting the screen puts text in the wrong place</li>
</ul>
<p>Here are some of the corresponding bug reports:</p>
<ul>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/199285">Ubuntu
#199285 - xterm crashes when compiz is on</a></li>
<li><a href=
"http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=467399">Debian
#467399 - compiz fails to take control of windows</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/xfce4-terminal/+bug/378668">
Ubuntu #378668 - Cursor in terminal behaves badly with special
characters present</a></li>
<li><a href=
"https://bugzilla.novell.com/show_bug.cgi?id=622936">Novell
#622936 - xterm: font drawing glitch</a></li>
<li><a href=
"https://bugzilla.redhat.com/show_bug.cgi?id=583904">Redhat
#583904 - gnome-terminal and xterm show garbled fonts with
compiz enabled (intel graphics)</a></li>
<li><a href=
"https://bugzilla.redhat.com/show_bug.cgi?id=614542">Redhat
#614542 - xterm graphical corruption when compiz is active</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/635258">Ubuntu
#635258 - Garbled chars in xterm</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/644943">Ubuntu
#644943 - xterm fonts get corrupted while typing</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/701160">Ubuntu
#701160 - /usr/bin/xterm is not functional in natty</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/700477">Ubuntu
#700477 - Font corruption in xterm under Lucid</a></li>
<li><a href=
"https://bugzilla.novell.com/show_bug.cgi?id=681359">Novell
#681359 - xterm: no data shown under the screen program</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/711894">Ubuntu
#711894 - iconic option does not work with compiz</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/xterm/+bug/778439">Ubuntu
#778439 - Typing "exit" in xterm kills X session</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/831336">
Ubuntu #831336 - running 'xterm' crashes X server</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/841103">Ubuntu
#841103 - Text has artifacts when typing something else</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/844454">Ubuntu
#844454 - Garbled chars in xterm (Onieric)</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1002972">
Ubuntu #1002972 - xterm moves to upper left when clicking titel
bar</a></li>
<li><a href=
"https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/1007722">
Ubuntu #1007722 - xterm doesn't display all the information</a></li>
</ul>
<p>Since the problem was not in xterm, all I could do is to help
forward those bug-reports to whatever package owns
<code>compiz</code>. What these had in common is that someone
wrote code which was tested against only a small subset of the X
protocol.</p>
<p>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.</p>
<ul>
<li>For instance, <a href=
"http://force.subcritical.org/xterm_under_compiz/">this
comment</a> by Eric Williams suggested that the problem could
be worked around by setting xterm's <code>borderWidth</code>
resource to zero.</li>
<li>other comments suggested turning off the "desktop effects"
or "animation".</li>
<li>On my machines using the default <em>Ubuntu</em> desktop, I
could see misbehavior easily in Ubuntu 12.04 using <a href=
"/vttest/vttest.html">vttest</a>. However, Ubuntu 12.04
provided <em>Ubuntu 2D</em>, which did not show those
problems (and was noticeably faster).</li>
</ul>
<p>Ubuntu dropped <em>compiz</em> in 2017. Its replacement (GNOME
shell) has fewer bugs.</p>
<h3 id="my_xdefaults-id"><a name="my_xdefaults" id=
"my_xdefaults">Sample .Xdefaults Color-Settings for XTerm</a></h3>
<p>This example dates from March 1997:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"ident2">internalBorder</span>:<span class=
"literal"> </span><span class="number">10</span><br>
<span class="keyword">XTerm</span>*<span class=
"ident2">highlightSelection</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorBDMode</span>:<span class=
"literal"> on</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorBD</span>:<span class=
"literal"> blue</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorULMode</span>:<span class=
"literal"> on</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorUL</span>:<span class=
"literal"> magenta</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">eightBitInput</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">eightBitOutput</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
<span class="keyword">XTerm</span>*<span class=
"ident2">scrollBar</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">titeInhibit</span>:<span class=
"literal"> </span><span class=
"keyword">true</span><br>
<br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorMode</span>:<span class=
"literal"> on</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">dynamicColors</span>:<span class=
"literal"> on</span><br>
<br>
<span class=
"comment">! Uncomment this to use color for underline attribute<br>
</span> <span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorULMode</span>:<span class=
"literal"> on</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">underLine</span>:<span class=
"literal"> off</span><br>
<br>
<span class=
"comment">! Uncomment this to use color for the bold attribute<br>
</span> <span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorBDMode</span>:<span class=
"literal"> on</span><br>
<br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color0</span>:<span class=
"literal"> black</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color1</span>:<span class=
"literal"> red3</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color2</span>:<span class=
"literal"> green3</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color3</span>:<span class=
"literal"> yellow3</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color4</span>:<span class=
"literal"> blue3</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color5</span>:<span class=
"literal"> magenta3</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color6</span>:<span class=
"literal"> cyan3</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color7</span>:<span class=
"literal"> gray90</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color8</span>:<span class=
"literal"> gray30</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color9</span>:<span class=
"literal"> red</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color10</span>:<span class=
"literal"> green</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color11</span>:<span class=
"literal"> yellow</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color12</span>:<span class=
"literal"> blue</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color13</span>:<span class=
"literal"> magenta</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color14</span>:<span class=
"literal"> cyan</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">color15</span>:<span class=
"literal"> white</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorUL</span>:<span class=
"literal"> yellow</span><br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">colorBD</span>:<span class=
"literal"> white</span><br>
<br>
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">cursorColor</span>:<span class=
"literal"> lime green</span><br>
<!--atr2html}}--></p>
</blockquote>
<p><strong>XTerm</strong> comes with two copies of each resource
file, one with color only (<code>XTerm-col.ad</code>, which is
installed as <code>XTerm-color</code>), and the regular one
(<code>XTerm.ad</code>, installed as <code>XTerm</code>). To use
the <code>XTerm-color</code> file in conjunction with a separate
<code>XTerm</code> app-defaults file which does not contain
color, add the following line to your <code>.Xdefaults</code>
file:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
*<span class="ident2">customization</span>:<span class=
"literal"> -color</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>Since 1997, the resource files grew in size and number.
Besides <code>XTerm</code> and <code>XTerm-color</code>, there
are also resource files for <strong>xterm</strong> using
different <em>class</em> values, together with the
<code>-color</code> flavors of these. Because the
<code>-color</code> flavors differ only by an
<code>#include</code> statement, the makefile generates these
from <a href=
"https://github.com/ThomasDickey/xterm-snapshots/blob/master/XTerm-col.ad">
XTerm-col.ad</a>. Here are the others:</p>
<blockquote>
<table border="1" summary="resource files for XTerm">
<tr>
<th>Program</th>
<th>Resource</th>
</tr>
<tr>
<td><a href="#xterm_man">xterm</a>
</td>
<td><a href=
"https://github.com/ThomasDickey/xterm-snapshots/blob/master/XTerm.ad">
XTerm</a>
</td>
</tr>
<tr>
<td><a href="#uxterm_man">uxterm</a>
</td>
<td><a href=
"https://github.com/ThomasDickey/xterm-snapshots/blob/master/UXTerm.ad">
UXTerm</a>
</td>
</tr>
<tr>
<td><a href="#koi8rxterm_man">koi8rxterm</a>
</td>
<td><a href=
"https://github.com/ThomasDickey/xterm-snapshots/blob/master/KOI8RXTerm.ad">
KOI8RXTerm</a>
</td>
</tr>
</table>
</blockquote>
<p>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 <code>app-defaults</code> file, I use
this feature from X:</p>
<blockquote>
<p class="code-block">Directories named by the environment
variable <code>XUSERFILESEARCHPATH</code> or the environment
variable <strong><code>XAPPLRESDIR</code></strong> (which names
a single directory and should end with a ‘/’ on
POSIX systems), plus directories in a standard place (usually
under <em><code>/usr/share/X11/</code></em>, but this can be
overridden with the <em><code>XFILESEARCHPATH</code></em>
environment variable) are searched for for application-specific
resources. For example, application default resources are
usually kept in
<em><code>/usr/share/X11/app-defaults/</code></em>. See the
<em>X Toolkit Intrinsics – C Language Interface</em>
manual for details.</p>
</blockquote>
<p>That is, if you set the <code>XAPPLRESDIR</code> 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 <code>.Xdefaults</code> file.</p>
<p>On the opposite extreme, some people advise using
<code>xrdb</code>. 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</p>
<ul>
<li>using <code>xrdb</code> prevented you from changing things
dynamically.</li>
<li>it was like using a hammer (nailing things down to prevent
them from being different).</li>
<li>when the only tool you know how to use is a hammer,
<a href="https://www.google.com/search?q=hammer+nail+problem&tbm=isch&tbo=u&source=univ&sa=X&ved=0ahUKEwigkLaixZLPAhWGWCYKHVD5B0sQsAQIUQ">
all of the problems look like nails</a>.</li>
<li>a good developer knows how to use more than one tool.</li>
</ul>
<h3 id="warning_msg-id"><a name="warning_msg" id=
"warning_msg">What is this warning message?</a></h3>
<dl>
<dt id="warning_errno">xterm: Error 11, errno 22: permission
denied</dt>
<dd>
Actually, any message like this denotes a failure which
requires studying the xterm source to determine the exact
problem.
<p>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.</p>
<p>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.</p>
</dd>
<dt id="warning_preedit">input method doesn't support my
preedit type</dt>
<dd>
Ignore this if you do not know what <em>input method</em> 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.
<p>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:</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"ident2">openIm</span>:<span class=
"keyword">false</span><br>
<!--atr2html}}--></p>
</blockquote>
</dd>
<dt id="warning_action">Warning: Actions not found: ignore,
"<em>xxx</em>"</dt>
<dd>
The action "<em>xxx</em>" (for example "scroll-back") is
specified in a resource file whose translations match widgets
that do not support them. For example, this
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"ident2">translations</span>:<span class=
"literal"> #override\n\<br>
</span><span class="keyword"><Leave></span><span class="literal">, ~Ctrl ~Meta </span><span class="keyword"><Btn2Up></span><span class="literal">: ignore()\n\<br>
~Shift </span><span class="keyword"><Key></span><span class="literal">KP_8: scroll-back(</span><span class="number">1</span><span class="literal">,line)\n\<br>
~Shift </span><span class="keyword"><Key></span><span class="literal">KP_2: scroll-forw(</span><span class="number">1</span><span class="literal">,line)\n\<br>
Shift </span><span class="keyword"><Key></span><span class="literal">KP_8: scroll-back(</span><span class="number">1</span><span class="literal">,halfpage)\n\<br>
Shift </span><span class="keyword"><Key></span><span class="literal">KP_2: scroll-forw(</span><span class="number">1</span><span class="literal">,halfpage)</span><br>
<!--atr2html}}--></p>
</blockquote>
<p>will produce warnings such as</p>
<blockquote>
<pre class="code-block">
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
</pre>
</blockquote>
<p>This is a correct form, assigning the actions to the
"VT100" widget.</p>
<blockquote class="code-block">
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;">
<span class="keyword">XTerm</span>*<span class=
"keyword">VT100</span>.<span class=
"ident2">translations</span>:<span class=
"literal"> #override\n\<br>
</span><span class="keyword"><Leave></span><span class="literal">, ~Ctrl ~Meta </span><span class="keyword"><Btn2Up></span><span class="literal">: ignore()\n\<br>
~Shift </span><span class="keyword"><Key></span><span class="literal">KP_8: scroll-back(</span><span class="number">1</span><span class="literal">,line)\n\<br>
~Shift </span><span class="keyword"><Key></span><span class="literal">KP_2: scroll-forw(</span><span class="number">1</span><span class="literal">,line)\n\<br>
Shift </span><span class="keyword"><Key></span><span class="literal">KP_8: scroll-back(</span><span class="number">1</span><span class="literal">,halfpage)\n\<br>
Shift </span><span class="keyword"><Key></span><span class="literal">KP_2: scroll-forw(</span><span class="number">1</span><span class="literal">,halfpage)</span><br>
<!--atr2html}}--></p>
</blockquote>
</dd>
<dt id="alloc_color-id"><a name="alloc_color" id=
"alloc_color">Warning: Cannot allocate colormap entry for
"<em>xxx</em>"</a>
</dt>
<dd>
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.
<p>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 <a href="/dialog/dialog.html">dialog</a>
unreadable.</p>
<p>This problem is alleviated with <a href=
"xterm.log.html#xterm_129">patch 129</a>, 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.</p>
</dd>
</dl>
<h2 id="known_bugs-id"><a name="known_bugs" id="known_bugs">Known
Bugs in <strong>XTerm</strong> and Look–alikes</a></h2>
<p>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).</p>
<p>Note that of the emulators that support color, some do not
support <code>bce</code> (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 <code>bce</code> (or allowing the choice between it
and its complement) is not a bug, since few hardware terminals
(with good reason) implemented this feature.</p>
<ul>
<li>cut/paste does not <a href=
"xterm.faq.html#xterm_tabs">select tabs</a>; 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.</li>
<li>does not implement the autorepeat feature of VTxxx
terminals.</li>
</ul>
<h3 id="bug_xterm_r6-id"><a name="bug_xterm_r6" id=
"bug_xterm_r6">X11R6.3 <strong>XTerm</strong></a></h3>
<p>The X Consortium version of xterm (and versions based on it)
has additional bugs not in modern xterm:</p>
<ul>
<li>the program must be run with fixed (nonproportional)
fonts.</li>
<li>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).</li>
<li>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.</li>
<li>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.</li>
<li>certain types of key translations cause a core dump because
the program does not check the event class before attempting to
use events.</li>
</ul>
<p>(These bugs are also present in the X11R5 version).</p>
<p id="xterm-xorg-id"><a name="xterm-xorg" id=
"xterm-xorg"><em>Update 2004/04/08:</em></a><br>
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.</p>
<p><em>As of 2009</em>, 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.</p>
<p><em>Reviewing in 2014</em>, 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
<a href="#xterm_pageup">here</a>:</p>
<ul>
<li>AIX provides a copy of <a href="/luit/luit.html">luit</a>,
and a corresponding <a href=
"http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.cmds%2Fdoc%2Faixcmds3%2Fluit.htm">
manpage</a>—which omits the sections on security, bugs
and attribution.</li>
<li>The <a href=
"http://publib.boulder.ibm.com/infocenter/aix/v7r1/index.jsp?topic=%2Fcom.ibm.aix.cmds%2Fdoc%2Faixcmds6%2Fxterm.htm">
xterm</a> 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.</li>
</ul>
<p>The other vendors provide documentation which is more
up-to-date.</p>
<h3 id="bug_color_xterm-id"><a name="bug_color_xterm" id=
"bug_color_xterm">COLOR_XTERM</a> <a href=
"ftp://ftp.x.org/contrib/applications/color_xterm-beta1.tar.gz">download</a></h3>
<p>This is based on the X Consortium X11R5 source, with the same
bugs.</p>
<ul>
<li>implements non-bce color model</li>
<li>moving the cursor is reported to leave trails of incorrect
color</li>
<li>clearing the screen resets colors (arguably this is a
limitation).</li>
</ul>
<p>Not exactly a bug, but it does not build on Linux with
X11R6.3</p>
<h3 id="bug_ansi_xterm-id"><a name="bug_ansi_xterm" id=
"bug_ansi_xterm">ANSI_XTERM</a> <a href=
"ftp://ftp.x.org/contrib/applications/xterm-R6-sb_right-ansi-3d.tar.gz">
download</a></h3>
<p>This is based on the X Consortium source, with the same
bugs.</p>
<ul>
<li>implements non-bce color model</li>
<li>fails <a href="/vttest/vttest.html">vttest</a> by not
rendering reverse-video screen</li>
</ul>
<h3 id="bug_cxterm-id"><a name="bug_cxterm" id=
"bug_cxterm">CXTERM</a> <a href=
"ftp://ftp.cuhk.hk/pub/chinese/ifcss/software/x-win/cxterm/">download</a></h3>
<p>CXterm stands for "Chinese Xterm". This is based on the X
Consortium source.</p>
<h3 id="bug_dtterm-id"><a name="bug_dtterm" id=
"bug_dtterm">DTTERM</a></h3>
<p>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.</p>
<ul>
<li>implements non-bce color model</li>
<li>fails <a href="/vttest/vttest.html">vttest</a> by clearing
its background to solid white rather than preserving its sense
in response to ED.</li>
<li>under some circumstances, scrolling margins are not
recognized. For instance, running <a href=
"/vile/vile.html">vile</a> which uses scrolling margins, we see
text overwriting the status line.</li>
</ul>
<h3 id="bug_emu-id"><a name="bug_emu" id="bug_emu">EMU 1.3</a>
<a href=
"ftp://ftp.x.org/contrib/applications/emu-1.31.tar.gz">download</a></h3>
<p>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
<a href="/vttest/vttest.html">vttest</a> on this emulator.</p>
<h3 id="bug_eterm-id"><a name="bug_eterm" id=
"bug_eterm">ETERM</a> <a href=
"http://www.eterm.org/">link</a></h3>
<p>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 <a href=
"/vttest/vttest.html">vttest</a> 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 <em>Eterm</em> through 0.9.</p>
<h3 id="bug_gnometerm-id"><a name="bug_gnometerm" id=
"bug_gnometerm">GNOME TERMINAL</a> <a href=
"http://www.gnome.org/">link</a></h3>
<p>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.</p>
<p>Starting in 1999 —</p>
<p>GNOME Terminal is developed separately from both xterm and
rxvt, and was originally based on the <a href=
"http://www.fifi.org/doc/gnome-dev-doc/html/zvt/book1.html">zvt
(zterm) widget</a>. Like <a href="#bug_kvt">kvt</a>), 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 <a href=
"/vttest/vttest.html">vttest</a>. 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</p>
<blockquote>
<pre class="code-block">
\E[>c
</pre>
</blockquote>
<p>expecting a response such as</p>
<blockquote>
<pre class="code-block">
\E[>0;138;0c
</pre>
</blockquote>
<p>for vt100. The bug report indicates that the "c" sent by vim
is echoed rather than interpreted by the emulator.</p>
<p>But it suffices for vi.</p>
<p>Moving on to 2001 —</p>
<p>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 <a href=
"/vttest/vttest.html">vttest</a>). 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).</p>
<p>Moving on to 2002 —</p>
<p>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):</p>
<ul>
<li>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.</li>
<li>the parser <code>src/vte.c</code> —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.</li>
</ul>
<p>Jumping to 2010 —</p>
<p>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.
<a href=
"https://bugzilla.redhat.com/show_bug.cgi?id=122815">Here</a> is
a related bug report, for key bindings.</p>
<p id="vte:xconsortium">The documentation for GNOME Terminal
asserts:</p>
<blockquote class="code-block">
<p>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.</p>
</blockquote>
<p>That sounds fine, except that it is both inaccurate and
misleading:</p>
<blockquote>
<dl>
<dt>inaccurate</dt>
<dd>
combining the "X Consortium" and "DEC VT220", for example,
since that was done after the demise of said organization.
<p>It emulates a <em>subset</em> 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.</p>
<p>Even in the subset which it emulates, GNOME Terminal has
bugs. Many of these are easy to demonstrate with
vttest.</p>
</dd>
<dt>misleading</dt>
<dd>as noted in <a href="#ctlseqs_ms">Xterm Control
Sequences</a>, xterm (mostly after "X Consortium") supports
control sequences which are not VT100/VT220. GNOME Terminal
implements many of these, but not all.</dd>
</dl>
</blockquote>
<p>Perhaps that was unintentional – GNOME developers did
not appear to document what their program <em>does</em> 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.</p>
<p>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.</p>
<p>Revisiting in 2018 —</p>
<p>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:</p>
<p><a href=
"https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=127622"><em>#127622:
ncurses-term: terminfo entry for gnome-terminal swaps
Backspace/Delete</em></a>:</p>
<blockquote>
<pre class="code-block">
>> "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
</pre>
</blockquote>
<p>The manual page provided as an attachment to GNOME <a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=311565#c15">#311565</a>
identifies the author. However, four years later there is still
no manpage for GNOME Terminal. GNOME <a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=701691">#701691</a>
mentions this in conjunction with GNOME Terminal's incompatible
behavior versus other terminals for the
“<code>-e</code>” option:</p>
<blockquote>
<pre class="code-block">
Christian Persch 2013-06-06 11:10:43 UTC
This works as designed. Note that both -x and -e are deprecated; the only supported way to pass the arguments is after -- like this:
$ gnome-terminal -- emacs file
</pre>
</blockquote>
<p>and</p>
<blockquote>
<pre class="code-block">
Christian Persch 2013-06-06 16:02:54 UTC
There are no docs for the gnome-terminal command line options.
</pre>
</blockquote>
<p>Admittedly, GNOME Terminal has <em>some</em> documentation, in
its online help pages. As mentioned, the misleading comments
about <em>X Consortium</em> 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:</p>
<ul>
<li><a href=
"https://git.gnome.org/browse/gnome-terminal/commit/?id=13ece45d6398e0ebe9aa06cc8da2148534ca8af6">
<em>help: update introduction.page</em></a> (2013-01-10)</li>
<li><a href=
"https://git.gnome.org/browse/gnome-terminal/commit/?id=dd1c5125c785f644954010052ee3e4c7783c08da">
<em>help: review</em></a> (2013-01-09)</li>
<li><a href=
"https://git.gnome.org/browse/gnome-terminal/commit/?id=317b05f46807ea60fbd6a0ed493824a2269dcc60">
<em>help: modified help in accordance with last review</em></a>
(2013-01-09)</li>
<li><a href=
"https://git.gnome.org/browse/gnome-terminal/commit/?id=13ece45d6398e0ebe9aa06cc8da2148534ca8af6">
<em>help: write instroduction.page</em></a> (2013-01-08)</li>
<li><a href=
"https://git.gnome.org/browse/gnome-terminal/commit/?id=8a4b9e67bc8f6a19e62c58650a635de6178911bd">
<em>help: start rewrite in Mallard</em></a> (2013-01-08)</li>
</ul>
<p>The document editors removed this statement</p>
<blockquote class="code-block">
<p>Run any application that is designed to run on VT102, VT220,
and <code>xterm</code> terminals</p>
</blockquote>
<p>as well as the extended comment about the <a href=
"#vte:xconsortium">X Consortium</a>, and replaced it with a less
specific statement.</p>
<blockquote class="code-block">
<p><code>Terminal</code> is a terminal emulator application for
accessing a UNIX shell environment which can be used to run
programs available on your system.</p>
<p><code>Terminal</code> supports escape sequences that control
cursor position and colors.</p>
</blockquote>
<p>The assertion about GNOME-Terminal's support for
“any” persisted in its <a href=
"https://packages.debian.org/sid/gnome-terminal">package
description</a> in Debian as of 2018:</p>
<blockquote class="code-block">
<ul>
<li>Access a UNIX shell in the GNOME environment.</li>
<li>Run any application that is designed to run on VT102,
VT220, and xterm terminals.</li>
</ul>
</blockquote>
<p>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</p>
<blockquote>
<pre class="code-block">
gnome-terminal --help-all
</pre>
</blockquote>
<p>Other programs do the equivalent. In a quick check using
Debian 8:</p>
<ul>
<li>85 lines for konsole</li>
<li>120 lines for xterm patch #331</li>
<li>122 lines for mlterm</li>
<li>140 lines for urxvt</li>
</ul>
<p>Bug <a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=311565#c15">#311565</a>
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.</p>
<h3 id="vte_widget-id"><a name="vte_widget" id="vte_widget">Notes
on VTE</a></h3>
<p>VTE is used by developers who provide a <a href=
"http://best-practice-software-engineering.ifs.tuwien.ac.at/patterns/facade.html">
facade</a> (also referred to as a “<a href=
"https://techterms.com/definition/skin">skin</a>”) for
simple desktop-oriented terminal emulation. <a href=
"http://www.calno.com/evilvte">This page</a> 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.</p>
<p>For more than <a href=
"https://git.gnome.org/browse/vte/diff/README?id=4e253be9282829f594c8a55ca08d1299e80e471d">
ten years</a>, VTE's README file asserted</p>
<blockquote class="code-block">
<p>VTE supports Unicode and character set conversion, as well
as emulating any terminal known to the system's terminfo
database.</p>
</blockquote>
<p>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.</p>
<p>Notes from 2010 —</p>
<p>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
<a href="https://git.gnome.org/browse/vte/log/">git-log</a>.</p>
<p>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.</p>
<p>xterm on the other hand, can be told with the <a href=
"manpage/xterm.html#Application-Resources:tcapFunctionKeys"><code>
tcapFunctionKeys</code></a> 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.</p>
<p>Outside of function-keys, VTE provided no ability to emulate
“any terminal”. A casual glance at its source code
revealed the following:</p>
<ul>
<li>no support for VT220-style protected areas.</li>
<li>inconsistent support for modifier keys (the subject of
several bug reports misdirected toward ncurses).</li>
<li>only a subset of the standard terminfo/termcap properties
is used (5/36 booleans, 3/33 numbers, 125/242 strings other
than function-keys).</li>
<li>a pervasive assumption that the terminal is something like
xterm, e.g., to provide hardcoded behavior where termcap might
describe something different.</li>
<li>it uses termcap to retrieve data, rather than providing a
choice between terminfo/termcap, opening up the problem of
using an obsolete database.</li>
<li>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.</li>
</ul>
<p>For instance, VTE cannot emulate <a href=
"xterm.faq.html#bug_dtterm">dtterm</a>, 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.</p>
<p>After 2014 —</p>
<p>Until 2014, VTE used a <em>termcap</em> file, with its own
<em>reader</em>, 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
<em>termcap</em> was a nuisance, whether it was bundled with VTE
(and inaccessible to users) or not. The developers tried it both
ways.</p>
<p>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 <em>modified</em> keys were
correct, since none of those are described by termcap. That meant
that a <em><strong>control</strong></em> modifier with a
cursor-key or function key was likely to be misread by programs
running in VTE.</p>
<p>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
<em>reader</em>. That did not work well, and finally they
discarded the whole feature, hardcoding the behavior to match
xterm's default configuration.</p>
<p>Here are bug reports which give the story:</p>
<ul>
<li>
<p><a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=600659">#600659
– <em>Home/End generate wrong control
sequences</em></a>.</p>
<pre class="code-block">
Escape sequences of the "default" kbd mode should be okay now.
Removal of non-default kbd modes is continued in bug 730137.
</pre>
</li>
<li>
<p><a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=169295">#169295
– <em>builtin termcap parser not needed</em></a>.</p>
<pre class="code-block">
all: Use terminfo instead of termcap
</pre>
</li>
<li>
<p><a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=730137">#730137
– <em>Drop (or fix) nondefault fkey modes</em></a>.</p>
<p class="code-block">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.</p>
</li>
<li>
<p><a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=728900">#728900
– <em>use terminfo instead of termcap</em></a>.</p>
<p class="code-block">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.)</p>
</li>
</ul>
<p>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 <a href=
"https://en.wikipedia.org/w/index.php?title=ANSI_escape_code&type=revision&diff=816842550&oldid=815750533">
here</a> reminded me to check what VTE does when saving/restoring
the cursor position. It turns out that it does something similar,
because (see <a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=731205">#731205</a>
and <a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=741193">#741193</a>)
the developer studied xterm's source-code and imitated it (see
<a href=
"https://git.gnome.org/browse/vte/commit/?id=5a434e6c4457bdfe182a13213396e7a66a08f767">
source changes</a> and <a href=
"https://git.gnome.org/browse/vte/commit/?id=e549a0eebc82fde89134c15ead322dc199d99239">
followup fixes</a>). 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).</p>
<p>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:</p>
<ul>
<li>
<p>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).</p>
<p>Two thirds of the functions listed in the skeleton are
no-ops (<a href=
"https://gitlab.gnome.org/GNOME/vte/blob/86e1d0883b88d4899c9b398d9f0a1c51b9d86e8d/src/parser-cmd.hh#L125">not
implemented</a>). Some of those listed as implemented do not
work (see vttest <a href=
"/vttest/vttest-codepages.html#ISO-Latin-1">screenshot</a>).</p>
<p>Oddly enough, the developers decided to make the program
<a href=
"https://gitlab.gnome.org/GNOME/vte/blob/86e1d0883b88d4899c9b398d9f0a1c51b9d86e8d/src/vteseq.cc#L2316">
claim that it is a VT525</a>, 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.</p>
</li>
<li>
<p>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 <a href=
"https://bugzilla.gnome.org/buglist.cgi?quicksearch=ctlseqs">(see
bug reports)</a> along with xterm's source-code rather than
<a href=
"https://bugzilla.gnome.org/buglist.cgi?quicksearch=ecma-48">ECMA-48</a>
or DEC's manuals until around the end of 2016.</p>
</li>
<li>
<p>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.,
<a href="https://github.com/kovidgoyal/kitty">kitty</a> (yet
another copyist: see <a href=
"https://github.com/jwilm/alacritty">alacritty</a>, but also
see <a href="https://github.com/jwilm/vte">this</a>).</p>
</li>
<li>
<p>Introducing those ECMA-48 features caused additional
failures for VTE versus <a href=
"/vttest/vttest.html">vttest</a>, 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).</p>
<p>ECMA-48 specifies the <em>active line</em> in selection 2.
For an explanation of the term, see ECMA-48 section
<em><strong>6.1.5</strong> Relationship between active data
position and active presentation position</em>. This is
distinct from the feature which DEC's terminals
supported.</p>
<p>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.</p>
</li>
<li>
<p>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.</p>
<p>At the time the VTE developers copied the feature, they
had not begun to develop support bi-directional text (see for
example <a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=321490"><em>#321490
(vtebidi)</em></a> and <a href=
"https://bugzilla.gnome.org/show_bug.cgi?id=767529"><em>#767529
(vteemoji)</em></a>.</p>
<p>At this writing (two years later), the developers are
talking about working on that. The tab-clear operation is
still <a href=
"https://gitlab.gnome.org/GNOME/vte/blob/86e1d0883b88d4899c9b398d9f0a1c51b9d86e8d/src/vteseq.cc#L7710">
identical in VTE</a> for both selections 2 and 3, and does
not implement any of the features from ECMA-48
<strong>not</strong> in a DEC terminal.</p>
</li>
</ul>
<p>Other problems with VTE —</p>
<p>These are a few of the interesting bugs found in VTE (or GNOME
Terminal) during 2017:</p>
<ul>
<li>
<p>system crash due to running out of memory<br>
while running ncurses sample programs <a href=
"/ncurses/ncurses-slang.html#compare_dots">dots</a> and
<a href=
"/ncurses/ncurses-slang.html#compare_picsmap">picsmap</a>.</p>
</li>
<li>
<p>failure to open a remote connection, noticed<br>
while gathering data for a <a href="#scroll_speed">discussion
of scrolling performance</a>.</p>
</li>
</ul>
<p>Other uses of VTE —</p>
<p>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:</p>
<ul>
<li>
<p><a name="bug_osso_xterm" id=
"bug_osso_xterm">osso-xterm</a> <a href=
"http://maemo.org/development/tools/doc/diablo/osso-xterm/">link</a></p>
<p>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.</p>
</li>
<li>
<p><a name="bug_roxterm" id="bug_roxterm">roxterm</a>
<a href="http://roxterm.sourceforge.net/">link</a></p>
</li>
<li>
<p><a name="bug_xfce_term" id="bug_xfce_term">XFCE
Terminal</a> <a href=
"http://terminal.os-cillation.com/">link</a></p>
</li>
</ul>
<h3 id="bug_multignome-id"><a name="bug_multignome" id=
"bug_multignome">MULTI GNOME TERMINAL (MGT)</a> <a href=
"http://multignometerm.sourceforge.net/">link</a></h3>
<p>Of particular note, MGT 1.4.0 announcement claims that it
works properly for all of <a href=
"/vttest/vttest.html">vttest</a>)'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.</p>
<h3 id="bug_hanterm-id"><a name="bug_hanterm" id=
"bug_hanterm">HANTERM</a> <a href=
"http://www.debian.org/Packages/frozen/x11/hanterm.html">download</a></h3>
<p>HanTerm stands for "Hangul term" (Korean). This is based on
the XFree86 source.</p>
<h3 id="bug_konsole-id"><a name="bug_konsole" id=
"bug_konsole">KONSOLE</a> <a href=
"http://www.kde.org/">link</a></h3>
<p>More than just a rewrite of <a href=
"xterm.faq.html#bug_kvt">kvt</a> into C++. But there are several
incompatibilities between konsole (noted with version 1.0.2 in
late 2001) and xterm:</p>
<ul>
<li>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.</li>
<li><a href="/vttest/vttest.html">vttest</a>) 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).</li>
<li>konsole implements several features from XFree86 xterm, but
some are done incorrectly. In particular, the <a href=
"xterm.faq.html#xterm_tite">private setmode 1049</a> does not
save and restore the cursor, causing the cursor to be in
unexpected locations after exiting a fullscreen application
such as vi.</li>
</ul>
<p>The problems with setmode 1049 were fixed after some time;
other issues linger on.</p>
<p>Like <a href="#bug_gnometerm">GNOME Terminal</a>, konsole's
documentation is incomplete and inaccurate. This gem from its
handbook illustrates the problem:</p>
<blockquote class="code-block">
<p>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.</p>
</blockquote>
<p>The problem:</p>
<ul>
<li>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 <a href=
"xterm.faq.html#bug_kvt">kvt</a> would have been more accurate.
Lacking that context, we find nonfactual articles such as
<a href="http://everything2.com/index.pl?node=Konsole">this</a>
on the net.</li>
<li>for those lacking a proper education, the README was
apparently intended to be a humorous reference to Dante's
<em>Inferno</em>.</li>
<li>reading konsole's source code and considering "hacked to
death" can provide some occasion for humor. Enjoy.</li>
</ul>
<h3 id="bug_kterm-id"><a name="bug_kterm" id=
"bug_kterm">KTERM</a> <a href=
"ftp://ftp.x.org/contrib/applications/kterm-6.2.0.tar.gz">download</a></h3>
<p>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).</p>
<ul>
<li>implements non-bce color model</li>
<li>implements status line, but uses non-DEC escape sequences
for this.</li>
</ul>
<p>There is a variation of xvt (ancestor of rxvt) originally
known as <a name="bug_kvt" id="bug_kvt">kvt</a> bundled with
<a href="http://www.kde.org/">KDE</a> 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.</p>
<h3 id="bug_mlterm-id"><a name="bug_mlterm" href=
"http://mlterm.sourceforge.net/" id="bug_mlterm">MLTERM</a></h3>
<p>Mlterm is not based on xterm or rxvt source, though it
implements many of their features. It does fairly well with
<a href="/vttest/vttest.html">vttest</a>, except for some odd
misbehavior in operations that save/restore the cursor
position.</p>
<h3 id="bug_mterm-id"><a name="bug_mterm" id=
"bug_mterm">MTERM</a></h3>
<p>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".</p>
<blockquote>
<pre class="code-block">
(mouse@Lightning.McRCIM.McGill.EDU) Available:
larry.mcrcim.mcgill.edu (132.206.1.1) in
/X/mterm.src/mterm.ball-o-wax.
</pre>
</blockquote>
<p>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 <a href=
"ftp://ftp.rodents.montreal.qc.ca/mouse/X/mterm.src/">ftp</a>.
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 <a href="/vttest/vttest.html">vttest</a>
as the more widely known emulators.</p>
<h3 id="bug_mxterm-id"><a name="bug_mxterm" id=
"bug_mxterm">MXTERM</a></h3>
<p>There are several variants on this: xterm adapted for Motif
libraries. I have seen none that work properly:</p>
<ul>
<li><a href=
"https://web.archive.org/web/20110202044334/http://www.cmbi.kun.nl/~schaft/mxterm/mxterm.html">
MXTERM: a motif Xterm with character attributes color
rendered</a> 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).</li>
<li>
<a href=
"http://www.muquit.com/muquit/software/ansi_xterm/ansi_xterm.html">
ANSI Xterm with Motif Scrollbar</a> 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.
<p>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.</p>
<p>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.</p>
</li>
<li><a href=
"http://web.archive.org/web/*/http://www.fh-wilhelmshaven.de/~akcaagaa/index_mxterm.html">
mxterm</a> 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.</li>
</ul>
<h3 id="bug_nxterm-id"><a name="bug_nxterm" id=
"bug_nxterm">NXTERM</a></h3>
<p>Distributed with Redhat 5.2, it is a repackaging of <a href=
"#bug_ansi_xterm">xterm-sb_right-ansi</a>, to use the Xaw3d
widget set. This is based on the X Consortium X11R6 source, with
the same bugs.</p>
<ul>
<li>implements non-bce color model</li>
<li>does not implement SGR 39 and SGR 49, all attributes are
reset when changing colors.</li>
<li>popup menus do not appear to work.</li>
</ul>
<p>Starting with Redhat 6.0, <em>nxterm</em> is the XFree86 3.3.6
xterm. Unfortunately Redhat neglected to update their termcap for
nxterm to match the program.</p>
<h3 id="bug_rxvt-id"><a name="bug_rxvt" id="bug_rxvt">RXVT</a>
<a href="http://www.rxvt.org/">link</a></h3>
<p>Rxvt's manual page states the following unqualified
comment:</p>
<blockquote class="code-block">
<p>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.</p>
</blockquote>
<p>How much is <em>much less</em>? 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.</p>
<p>The toolkit-style configurability glibly referenced is the
ability to redefine keys on the keyboard without recompiling the
program, i.e., the <a href="#how2_fkeys">translations</a>
resource. It also is the way mouse events and other actions are
passed to xterm.</p>
<p>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).</p>
<p>This comment was topical in December 2001:</p>
<blockquote class="code-block">
<p>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.</p>
</blockquote>
<p id="rxvt_sizes_2010">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).</p>
<table border="1" summary="Comparing XTerm's size">
<tr>
<th>program</th>
<th>base size</th>
<th>total size</th>
<th>libraries</th>
</tr>
<tr>
<td>aterm</td>
<td>127</td>
<td>10763</td>
<td>45</td>
</tr>
<tr>
<td>color_xterm</td>
<td>142</td>
<td>3647</td>
<td>13</td>
</tr>
<tr>
<td>Eterm</td>
<td>1</td>
<td>5126</td>
<td>19</td>
</tr>
<tr>
<td>fbiterm</td>
<td>6</td>
<td>2424</td>
<td>8</td>
</tr>
<tr>
<td>gnome-terminal</td>
<td>292</td>
<td>14587</td>
<td>51</td>
</tr>
<tr>
<td>hpterm</td>
<td>146</td>
<td>14386</td>
<td>31</td>
</tr>
<tr>
<td>konsole</td>
<td>2</td>
<td>39815</td>
<td>71</td>
</tr>
<tr>
<td>kterm</td>
<td>226</td>
<td>4194</td>
<td>17</td>
</tr>
<tr>
<td>mlterm</td>
<td>316</td>
<td>6606</td>
<td>27</td>
</tr>
<tr>
<td>mrxvt</td>
<td>298</td>
<td>4515</td>
<td>19</td>
</tr>
<tr>
<td>multi-aterm</td>
<td>144</td>
<td>2821</td>
<td>7</td>
</tr>
<tr>
<td>pterm</td>
<td>405</td>
<td>12817</td>
<td>42</td>
</tr>
<tr>
<td>rxvt 2.6.4</td>
<td>108</td>
<td>2725</td>
<td>6</td>
</tr>
<tr>
<td>rxvt 2.7.10</td>
<td>152</td>
<td>2829</td>
<td>7</td>
</tr>
<tr>
<td>rxvt-unicode</td>
<td>1259</td>
<td>13641</td>
<td>49</td>
</tr>
<tr>
<td>terminal.app</td>
<td>211</td>
<td>15274</td>
<td>29</td>
</tr>
<tr>
<td>wterm</td>
<td>110</td>
<td>2922</td>
<td>11</td>
</tr>
<tr>
<td>xfce4-terminal</td>
<td>148</td>
<td>14059</td>
<td>48</td>
</tr>
<tr>
<td>xgterm</td>
<td>953</td>
<td>4602</td>
<td>14</td>
</tr>
<tr>
<td>xhpterm</td>
<td>130</td>
<td>2748</td>
<td>6</td>
</tr>
<tr>
<td>xiterm</td>
<td>12</td>
<td>3762</td>
<td>16</td>
</tr>
<tr>
<td>xterm (everything)</td>
<td>346</td>
<td>5484</td>
<td>24</td>
</tr>
<tr>
<td>xterm (minimal)</td>
<td>186</td>
<td>4123</td>
<td>15</td>
</tr>
<tr>
<td>xterm-r5</td>
<td>135</td>
<td>4164</td>
<td>11</td>
</tr>
<tr>
<td>xterm-r6</td>
<td>140</td>
<td>4169</td>
<td>11</td>
</tr>
</table>
<p>Counting the libraries is appropriate, since some programs
such as xiterm and the VTE-based programs are implemented in
libraries.</p>
<p>These comments apply to versions of <em>rxvt</em> through
2.21:</p>
<ul>
<li>clearing the screen resets colors</li>
<li>does not have a delete key</li>
<li>the implementation of <code>ech</code> (erase characters)
does not follow DEC VT220 (also ISO 6429), causing applications
using this function to misbehave.</li>
</ul>
<p>A newer version (upgraded to an beta as of 2.6.PRE3, however,
since it no longer dumps core in <a href=
"/vttest/vttest.html">vttest</a>) is reported to fix the
<code>ech</code> bug. However, it is less VT100-compatible than
the earlier versions such as 2.21b because it does not render
reverse video (<code>DECSCNM</code>) properly. All versions do
not update the screen frequently enough, making animation
ineffective. See <a href="/vttest/vttest.html">vttest</a>, tests
1 and 2.</p>
<p>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 <code>.Xdefaults</code> 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 <code>XTerm</code> 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.</p>
<p>That comment applies mainly to the resource
<strong>patterns</strong>. However, even when the pattern is
reasonably unambiguous, but overbroad, the results can be
conflicting. For example, some versions of rxvt may accept a
<code>font</code> resource which does not match the XLFD pattern.
It accepts a prefix of "xft:". This feature (apparently
introduced by <a href="#bug_konsole">konsole</a>) tells rxvt to
interpret the remainder of the string as a TrueType (Xft) font
rather than a bitmap font. xterm uses the <code>faceName</code>
resource for these values.</p>
<h3 id="bug_st-id">st <a name="bug_st" href=
"http://st.suckless.org" id="bug_st">link</a></h3>
<p>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.</p>
<p>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 <a href="xtoolkit/">X Toolkit
library</a>). 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:</p>
<table summary="ldd-size-fedora22" border="1">
<tr>
<th>LDD-Size</th>
<th>Program</th>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
3452986</td>
<td>rxvt</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
<em>6060960</em>
</td>
<td>st</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
6771039</td>
<td>mrxvt</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
<em>7785780</em>
</td>
<td>xterm</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
15060195</td>
<td>urxvt</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
20934874</td>
<td>lxterminal</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
21089908</td>
<td>lilyterm</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
21358156</td>
<td>xfce4-terminal</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
25738679</td>
<td>roxterm</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
31195794</td>
<td>gnome-terminal</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
32780414</td>
<td>terminology</td>
</tr>
<tr>
<td align="right" style="font-family: monospace;">
87813125</td>
<td>konsole</td>
</tr>
</table>
<p>By the way, the project page quotes the <a href=
"https://github.com/ThomasDickey/xterm-snapshots/blob/master/README">
README</a> file from xterm's sources, omitting my editorial
comment at the top noting that the <a href=
"https://www.phrases.org.uk/meanings/abandon-hope-all-ye-who-enter-here.html">
paraphrase</a> of the opening from Dante's <em>Inferno</em> dated
from 1991, and pointing to this FAQ to provide better
context.</p>
<h3 id="bug_xgterm-id"><a name="bug_xgterm" id=
"bug_xgterm">XGTERM</a> <a href=
"ftp://iraf.noao.edu/iraf/x11iraf/">link</a></h3>
<p>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.</p>
<p>That is from reading the source code. However testing under
Debian, something is wrong with the resource processing (neither
popup menus nor colors work).</p>
<p>As of March 2022, Debian's <a href=
"https://packages.debian.org/search?keywords=xgterm">xgterm</a>
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 <a href=
"/ncurses/terminfo.src.html#tic-xgterm">xgterm</a> terminal
description.</p>
<h3 id="bug_xiterm-id"><a name="bug_xiterm" id=
"bug_xiterm">XITERM</a> <a href=
"ftp://metalab.unc.edu/pub/Linux/X11/terms/">link</a></h3>
<p>This appears to be rxvt 2.20, lightly reformatted, with a few
ifdef's changed.</p>
<p>That is, it was. The name was later appropriated by a
different <a href=
"http://web.archive.org/web/*/http://oss.software.ibm.com/linux/projects/iterm/">
program</a>, which also uses the name <code>iterm</code>. Like
gnome-terminal, iterm aims to be an xterm-emulator rather than a
VT102- or VT220-emulator.</p>
<p>An earlier <a href=
"http://web.archive.org/web/*/http://www.openi18n.org">attempt</a>
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:</p>
<blockquote>
<pre class="code-block">
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(-)
</pre>
</blockquote>
<p>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 <code>bce</code> color model however, and Sun provided no
terminal description for it.</p>
<p>Back to <em>iterm</em>: the author's README in the patch used
the same terminology as in the later work, demonstrating their
relationship:</p>
<blockquote>
<pre class="code-block">
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.
</pre>
</blockquote>
<p>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 <em><a href=
"http://docs.oracle.com/cd/E19253-01/817-2521/os-1208/index.html">
International Language Environments Guide</a></em>, but in
explaining <em>how</em> this is done, the documentation is weak,
lacking detail.</p>
<p>Either version of <em>iterm</em> has similar problems running
<a href="/vttest/vttest.html">vttest</a>.</p>
<h2 id="building_it-id"><a name="building_it" id=
"building_it">How do I build <strong>XTerm</strong>?</a></h2>
<p>Building a copy of xterm is simple, provided that you have a
development configuration for X11:</p>
<ul>
<li>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 <code>Xaw</code> library for popup menus.</li>
<li>imake and <code>xmkmf</code>. These utilities produce a
Makefile from the Imakefile. They are not essential, but
useful, particularly on systems with unusual
configurations.</li>
</ul>
<p>If you have a working <code>xmkmf</code> script (or correctly
configured imake utility), all you need to do is type</p>
<blockquote>
<pre class="code-block">
xmkmf
make
</pre>
</blockquote>
<p>I have written a <em>configure</em> script for xterm which can
use <code>imake</code> (or <code>xmkmf</code>) to generate a
Makefile from the Makefile.in. Or it can do without
<code>imake</code> entirely. I have restructured xterm to
eliminate most hardcoded <code>#ifdef</code>'s, replacing them
with definitions that can be derived with the configuration
script. The <em>configure</em> script is more flexible than
<em>xmkmf</em>, since it allows you to enable or disable a
variety of features. Type</p>
<blockquote>
<pre class="code-block">
configure --help
</pre>
</blockquote>
<p>to get a list of options.</p>
<p>Though I have replaced most hardcoded ifdef's with
autoconfigured values, it will still continue to build properly
with the imake environment.</p>
<p>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 <a href="#narrowproto">Why doesn't the scrollbar
work?</a>) can be a problem.</p>
<p>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 <a href=
"/scripts/readme.html">here</a>. 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:</p>
<blockquote>
<pre class="code-block">
--- 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;
</pre>
</blockquote>
<p>I made note of it on the Xorg <a href=
"http://lists.x.org/archives/xorg-devel/2010-May/009052.html">mailing
list</a>, but as you can see, there was no response.</p>
<p>Finally, I spent the requisitve time to integrate the
change—and complete the process of transforming the
<a href="xtoolkit/"><em>X Toolkit</em></a> documentation from
nroff to docbook/xml.</p>
<h2 id="report_bugs-id"><a name="report_bugs" id=
"report_bugs">How do I report bugs?</a></h2>
<p>You should report bugs to <a href=
"mailto:dickey@invisible-island.net">me</a>. I also respond to
bug reports in a number of bug-tracking systems, though some are
less open to searches than others. See also:</p>
<ul>
<li><a href="/personal/bug-reports.html">reporting/patching</a>
procedures.</li>
<li><a href="/scripts/readme.html">analyzing problems with
configure scripts</a></li>
</ul>
<h2 id="more_info-id"><a name="more_info" id=
"more_info">Additional Information</a></h2>
<p>There appears to be no comprehensive source of information on
xterm better than the documentation which comes with the source
code</p>
<ul>
<li>
<a href="/xterm/xterm.log.html">XTerm change log</a>
<ul>
<li><a href="#xterm_man">The XTerm Manual</a></li>
<li><a href="#ctlseqs_ms">XTerm Control Sequences</a></li>
<li><a href="#resize_man">resize</a> – set TERMCAP
and terminal settings to current xterm window size</li>
<li><a href="#uxterm_man">uxterm</a> – a UTF-8
wrapper for XTerm</li>
<li><a href="#koi8rxterm_man">koi8rxterm</a> – a
KOI8-R wrapper for XTerm</li>
<li><a href="#luit_prog">luit</a> – Locale and ISO
2022 support for Unicode terminals</li>
</ul>
</li>
<li><a href="#other_sites">Other Sites</a></li>
<li><a href="#ref_misleading">Interesting but misleading</a></li>
</ul>
<h4 id="xterm_man-id"><a name="xterm_man" id="xterm_man">The
XTerm Manual</a></h4>
<p>The command-line options, X resources and similar configurable
options of xterm are documented in the manual page.</p>
<p>Here are copies of the file in various forms: <a href=
"/xterm/manpage/xterm.html">html</a>, <a href=
"/xterm/manpage/xterm.pdf">pdf</a>, <a href=
"/xterm/manpage/xterm.ps">ps</a> and <a href=
"/xterm/manpage/xterm.txt">text</a>.</p>
<h4 id="ctlseqs_ms-id"><a name="ctlseqs_ms" id="ctlseqs_ms">Xterm
Control Sequences</a></h4>
<p>Control sequences, i.e., programming information are in the
<code>ctlseqs.ms</code> file which I bundle with the <a href=
"xterm.faq.html#latest_version">program source</a>. (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.,</p>
<blockquote>
<pre class="code-block">
tbl ctlseqs.ms | nroff -ms >ctlseqs.txt
tbl ctlseqs.ms | groff -ms >ctlseqs.ps
</pre>
</blockquote>
<p>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.</p>
<p>Here are copies of the file in various forms: <a href=
"ctlseqs/ctlseqs.html">html</a>, <a href=
"ctlseqs/ctlseqs.pdf">pdf</a>, <a href=
"ctlseqs/ctlseqs.ps">ps</a> and <a href=
"ctlseqs/ctlseqs.txt">text</a>.</p>
<h4 id="resize_man-id"><a name="resize_man" id=
"resize_man">resize – set TERMCAP and terminal settings to
current xterm window size</a></h4>
<p><em>resize</em> is useful by itself, but is maintained for
historical reasons as part of xterm. <a href=
"/xterm/manpage/resize.html">html</a>, <a href=
"/xterm/manpage/resize.pdf">pdf</a>, <a href=
"/xterm/manpage/resize.ps">ps</a> and <a href=
"/xterm/manpage/resize.txt">text</a>.</p>
<h4 id="uxterm_man-id"><a name="uxterm_man" id=
"uxterm_man">uxterm – a UTF-8 wrapper for xterm</a></h4>
<p>XTerm does not automatically <em>set</em> your locale. It can
be told to <em>use</em> 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 <em>lxterm</em> script, but
it relies upon non-portable applications, unlike uxterm.</p>
<p>Here are copies of uxterm's documentation: <a href=
"/xterm/manpage/uxterm.html">html</a>, <a href=
"/xterm/manpage/uxterm.pdf">pdf</a>, <a href=
"/xterm/manpage/uxterm.ps">ps</a> and <a href=
"/xterm/manpage/uxterm.txt">text</a>.</p>
<p>Incidentally, there was a different program named "uxterm"
before the shell script was added to xterm in <a href=
"xterm.log.html#xterm_137">mid-2000</a>. <a href=
"https://web.archive.org/web/20130328091052/http://czyborra.com/unicode/terminals.html">
Roman Czyborra commented</a> 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 <a href=
"http://www.unicode.org/mail-arch/unicode-ml/Archives-Old/UML001/0042.html">
1994</a>, and the last was Czyborra's page in 1998. For the
curious, there is a copy on <a href=
"http://www.ibiblio.org/pub/packages/ccic/software/x-win/uxterm/uxterm.README">
ibiblio.org</a> (no Linux executables, no source, however).</p>
<h4 id="koi8rxterm_man-id"><a name="koi8rxterm_man" id=
"koi8rxterm_man">koi8rxterm – a KOI8-R wrapper for
xterm</a></h4>
<p>As a special case, this wrapper is packaged with xterm to
provide KOI8-R encoding.</p>
<p>Here are copies of koi8rxterm's documentation: <a href=
"/xterm/manpage/koi8rxterm.html">html</a>, <a href=
"/xterm/manpage/koi8rxterm.pdf">pdf</a>, <a href=
"/xterm/manpage/koi8rxterm.ps">ps</a> and <a href=
"/xterm/manpage/koi8rxterm.txt">text</a>.</p>
<h4 id="luit_prog-id"><a name="luit_prog" id="luit_prog">luit
– Locale and ISO 2022 support for Unicode terminals</a></h4>
<p><a href="/luit/luit.html">luit</a> 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.</p>
<h3 id="other_sites-id"><a name="other_sites" id=
"other_sites">Other Sites</a></h3>
<ul>
<li>
<p>I have found Richard Shuford's archive to be invaluable
for notes on the DEC VT220 and related terminals. This was a
<a href=
"http://web.eecs.utk.edu/~shuford/terminal_index.html">webpage</a>
but was last seen via <a href=
"ftp://cs.utk.edu/pub/shuford/">ftp</a>. I have a snapshot of
the ftp site, here:</p>
<ul>
<li><a href=
"/archives/shuford/">ftp://invisible-island.net/shuford/</a></li>
<li><a href=
"https://invisible-mirror.net/archives/shuford/">http://invisible-mirror.net/archives/shuford/</a></li>
</ul>
</li>
<li>
<p>Though not available at the time that I was collecting
most of my notes, <a href="http://vt100.net">VT100.net</a> is
also a good source of primary information.</p>
</li>
<li>
<p>As part of my <a href="/personal/git-exports.html"><em>Git
exports</em></a> work in 2016, I made a repository of the
major X release copies of <a href=
"https://github.com/ThomasDickey/old-xterm">xterm source</a>.
Alan Coopersmith has a more extensive repository of the
<a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/log/">X
source</a>, which is also useful although it does not cover
the full timespan. In my repository, I combined the
controls-sequences document which was in <em>specs</em> with
the program:</p>
<ul>
<li>xterm was first released in X10R3, with a manual page
in the <code>man</code> directory, and program in the
<code>xterm</code> directory.</li>
<li>The developers (re)organized the directory tree in X11,
moving some manual pages under the <code>doc</code> tree,
others went along with the source-code, and moving the
programs such as xterm under a <code>clients</code>
directory.</li>
<li>The control-sequences document was first released in
X11R4.</li>
<li>When making the repository, I overlooked the X10 manual
page. Git isn't flexible enough to add that later, without
re-creating the repository.</li>
</ul>
<p>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.</p>
<p>The dates shown are, of course, for the xterm
source-code:</p>
<table summary="historical xterm source code">
<tr>
<th rowspan="2">Date</th>
<th rowspan="2">Release</th>
<th>Mine</th>
<th>Alan's</th>
</tr>
<tr>
<th><a href=
"https://github.com/ThomasDickey/old-xterm/commits/8c1136d1b2593d44ef5e0c31f9917a8fb336443a/main.c">
old-xterm</a>
</th>
<th><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/log/xc/programs/xterm">
Program</a>
</th>
<th><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/log/xc/doc/specs/xterm">
Specs</a>
</th>
</tr>
<tr>
<td>2005-12-14</td>
<td><em>X11R6.9.0</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/8c1136d1b2593d44ef5e0c31f9917a8fb336443a">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>2005-01-12</td>
<td><em>X11R6.8.2</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/8f53683fb3286c4b9f7e56b035657c019a8b510c">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>2004-08-20</td>
<td><em>X11R6.8.0</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/244c3c87895b75f50d994c8ed0b0b0b570acb02b">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>2004-04-02</td>
<td><em>X11R6.7</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/72f78591baaef305e639393c8570f33154801342">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>2001-02-09</td>
<td><em>X11R6.6</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/588551b210f997e94d7062068e473b03dd7f7adc">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>2000-08-21</td>
<td><em>X11R6.5.1</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/6171bddbd473ca531a927f98253b617200a2f7de">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>1998-02-09</td>
<td><em>X11R6.4</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/09772a9703eeaf63ab990189453f64ea718c7005">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>1996-12-09</td>
<td><em>X11R6.3</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/593e9a29ebed6609b07f4133e034b43400e8cc51">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>1996-02-02</td>
<td><em>X11R6.1</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/1f18f60614c20fce722891b772017b5647eb9259">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>1995-01-30</td>
<td><em>X11R6</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/279c9960fc4d19e249ec7af2fb7c7d9c2987d369">
link</a>
</td>
<td><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/tree/xc/programs/xterm?id=9d5f53a3923a1a4bd6fa8afb3d7afdd448767187">
link</a>
</td>
<td><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/tree/xc/doc/specs/xterm/ctlseqs.ms?id=68409e15e071bae349d54111b27d9b78c1dd6c5a">
link</a>
</td>
</tr>
<tr>
<td>1993-11-11</td>
<td><em>X11R5</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/5534cf360d381e75057bef3eaf401acad5a6360e">
link</a>
</td>
<td><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/tree/xc/programs/xterm?id=8dd835dffa5a2928cec818fb0148c9c2838caa4b">
link</a>
</td>
<td><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/tree/xc/doc/specs/xterm/ctlseqs.ms?id=f9475442485638537e74bd44ea38d792eecdbecc">
link</a>
</td>
</tr>
<tr>
<td>1989-12-23</td>
<td><em>X11R4</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/aff055339109b8fe7bf146aecc340a622bae235e">
link</a>
</td>
<td><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/tree/xc/programs/xterm?id=ad6566ec83c49abca29536932627a41c9a1004da">
link</a>
</td>
<td><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/commit/xc/doc/specs/xterm?id=9b99668bad70ce523d88920d98ae7b686d9c3289">
link</a>
</td>
</tr>
<tr>
<td>1988-10-27</td>
<td><em>X11R3</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/1c2422714c26256ff4c3717d1529cec141f22b49">
link</a>
</td>
<td><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/tree/xc/programs/xterm?id=009e20249100057a1ae15f0c1c04f6d964c0dd81">
link</a>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>1988-03-01</td>
<td><em>X11R2</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/aaf6f073d6039955fa7fa56675a5ea10dc9e21b6">
link</a>
</td>
<td><a href=
"https://cgit.freedesktop.org/~alanc/xc-historical/tree/xc/programs/xterm?id=243d9b2d557b95812e51097e98d8f4be79df78d5">
link</a>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>1987-09-15</td>
<td><em>X11R1</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/6bf1714f13b7811c3e28d186bfc9942d971edd9b">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>1986-12-25</td>
<td><em>X10R4</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/d448c6d7373c3bc3df4c75e815baa1e645462893">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
<tr>
<td>1986-05-17</td>
<td><em>X10R3</em>
</td>
<td><a href=
"https://github.com/ThomasDickey/old-xterm/tree/28267a54e0b2f5daf75846ba8ee5030a1d177a52">
link</a>
</td>
<td><em>n/a</em>
</td>
<td><em>n/a</em>
</td>
</tr>
</table>
</li>
</ul>
<h3 id="ref_misleading-id"><a name="ref_misleading" id=
"ref_misleading">Interesting but misleading:</a></h3>
<ul>
<li id="mis:vt100-color">
<p>The ncurses FAQ <em><a href=
"/ncurses/ncurses.faq.html#vt100_color" id="vt100_color"
name="vt100_color">How do I get color with VT100?</a></em>
discusses a widely cited bit of misinformation.<br>
For instance, this <a href=
"https://www.google.com/search?q=%22http%3A%2F%2Fwww.termsys.demon.co.uk%2Fvtansi.htm%22">
web search</a> gives 3,000 hits in March 2015.</p>
</li>
<li id="mis:backspace-delete">
<p>Also widely cited, <a href=
"http://www.ibb.net/~anne/keyboard/keyboard.html">Consistent
BackSpace and Delete Configuration</a> gives advice regarding
<a href="#xterm_erase">backspace and delete</a> keys which is
heavily biased toward Linux. For instance:</p>
<ul>
<li>
<p>the <em>console</em> referred to is the Linux console,
which initially had as a goal <em>VT220</em> emulation.
Linux never came close to meeting that goal, which was
abandoned in the late 1990s when UTF-8 became more
important.</p>
<p>As part of that, Linux's keyboard was (actually
modelled on xterm) said to be <em>VT220</em>, and its
coding for the backspace key sent <code>DEL</code>. In
contrast, ncurses' terminal database says
<code>kbs</code> for the <a href=
"/ncurses/terminfo.src.html#tic-vt220">vt220</a> sends
<code>^H</code> (<code>BS</code>).</p>
</li>
<li>
<p>the guideline uses "newer", "right" and "correct" in
the part which describes <code>DEL</code>, versus "dirty"
and "break", "broken" in that addressing
<code>BS</code>.</p>
</li>
</ul>
<p>In addition to bias, the technical remedies are unsuitable
for generic advice. In particular, the comments about
terminfo, <code>xmodmap</code> and xterm's translations
resource are suitable only for special cases because the
proposed solutions create problems of their own.</p>
<p>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, <a href=
"http://unix.stackexchange.com/questions/180087/why-pressing-ctrl-h-in-xterm-tmux-sends/180106#180106">
this page</a>'s <em>accepted answer</em> recommends that
(although neither gives a useful answer to the question).
Here are a few clues:</p>
<ul>
<li>
<p>Debian's current package for ncurses uses the
<code>--with-xterm-kbs</code> configure option which I
added in <a href="/ncurses/NEWS.html#t20120211">2012</a>.
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.</p>
<p>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.</p>
</li>
<li>
<a href="http://tmux.sourceforge.net/">tmux</a> is
(mostly) a terminfo application. However, it does not use
the terminal database's <code>kbs</code> value. Rather
(referring to the source for 1.9a), it uses the termios
setting:
<blockquote>
<!--{{atr2html-->
<p style="font-family: monospace; font-size: 10pt;"
class="code-block">
<span class="comment">/*<br>
</span>
<span class="comment">* Check for backspace key using termios VERASE - the terminfo<br>
</span>
<span class="comment">* kbs entry is extremely unreliable, so cannot be safely<br>
</span>
<span class="comment">* used. termios should have a better idea.<br>
</span>
<span class="comment">*/</span><br>
bspace = tty->tio.c_cc[VERASE];<br>
<span class="keyword">if</span> (bspace != _POSIX_VDISABLE && key == bspace)<br>
key = KEYC_BSPACE;<br>
<!--atr2html}}--></p>
</blockquote>
<p>At the same time, <code>tmux</code> sets
<code>$TERM</code> to "screen", by default. Debian
patches that terminal description, too. Applications
running inside <code>tmux</code> use that terminal
description. If instead <code>tmux</code> translated the
backspace key to match the value from <a href=
"/ncurses/man/curs_termattrs.3x.html">erasechar</a> (for
the given <code>$TERM</code>), its clients would receive
consistent information.</p>
<p>Thus, rather than blaming the user (for a "badly
configured" xterm), the actual problem is a design flaw
in <code>tmux</code> which should have been sent to its
developers in a bug report.</p>
</li>
</ul>
</li>
<li id="mis:all-escapes">
<p>One of the PuTTY developers has a list named
“all-escapes” which begins</p>
<blockquote>
<pre class="code-block">
# This file is hoped to document all the escape sequences supported by
# terminals that are vaguely compliant with ECMA-48 and friends.
</pre>
</blockquote>
<p>It has been an occasional topic for comment:</p>
<ul>
<li>
<a href=
"https://comp.os.vms.narkive.com/xY2s5Mns/decterm-special-escape-sequences">
DECterm special escape sequences ?</a> (Fri Dec 29
08:28:11 2006 on <em>comp.os.vms</em>):
<blockquote>
<pre class="code-block">
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
> <<a rel="nofollow" href=
"http://bjh21.me.uk/all-escapes/all-escapes.txt">http://bjh21.me.uk/all-escapes/all-escapes.txt</a>> ...
...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
<a href=
"/archives/ncurses/terminfo.src.gz">ftp://invisible-island.net/ncurses/terminfo.src.gz</a>
or any of the references cited.
</pre>
</blockquote>
</li>
<li>
<a href=
"https://unix.stackexchange.com/questions/295871/why-does-cating-an-executable-keep-changing-the-title-of-putty?rq=1">
Why does cating an executable keep changing the title of
PuTTY?</a> (July 14, 2016 on StackOverflow)
<blockquote>
<pre class="code-block">
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.
</pre>
</blockquote>
<p>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 (<a href=
"xterm.log.html#xterm_116">xterm #116</a>). 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.</p>
<p>The file changes infrequently, but has changed within
the past year (in 2020). There is an <a rel="nofollow"
href=
"https://bjh21.me.uk/all-escapes/all-escapes.xhtml">xhtml
version</a>, perhaps inspired by <a rel="nofollow" href=
"http://rtfm.etla.org/xterm/ctlseq.html">this old
page</a> (also from 1999).</p>
</li>
</ul>
</li>
<li id="mis:ncdware">
<p>Noted <a href=
"http://stackoverflow.com/questions/24833129/how-to-change-the-window-title-of-te-based-on-vt320">
here</a>, someone pointed out an <a href=
"http://bio.gsi.de/DOCS/NCDWARE/V5.0.000/HTML/term_em8.htm">NCDware
document</a> describing its terminal control sequences.</p>
<p>Disregarding the title <em>Using VT320 Terminal Emulator
Escape Sequences</em>, 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".</p>
<p>The NCD documentation (dated December 12, 1997) does not
mention xterm. A <a href=
"http://www.textfiles.com/bitsavers/pdf/ncd/9300584A_NCDware_Reference_Manual_Oct1997.pdf">
related manual</a> does mention xterm, but only in other
sections. There are other issues with the manual. For
example, aixterm (<a href=
"/xterm/xterm.log.html#xterm_39">16-color</a>) control
sequences are documented as "NCD-specific values". NCD did
add escape sequences for status line (<a href=
"#bug_kterm">kterm</a> 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 <a href=
"/xterm/xterm.log.html#xterm_70">1998</a>).</p>
</li>
<li id="mis:geekery">
<p><em><a href=
"http://aperiodic.net/phil/archives/Geekery/term-function-keys.html">
Terminal Function Key Escape Codes</a></em> has good
intentions, but falls astray in several respects.<br>
For a different treatment of the same material, see my
notes:</p>
<blockquote>
<p><em><a href="/xterm/xterm-function-keys.html">Table of
function-keys for XTerm and other Terminal
Emulators</a></em>
</p>
</blockquote>
<p>First off, it (like the the <a href=
"#vte:xconsortium">documentation</a> for GNOME Terminal)
misattributes work which I did, crediting the X
Consortium:</p>
<blockquote class="code-block">
<p>This brings me to xterm. xterm has a long history, and
the function key definitions have changed over time. The
<strong>original</strong> 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 <strong>F48</strong>. F1 through F12 generated,
respectively, codes <code>^[[11~</code> to
<code>^[[15~</code>, <code>^[[17~</code> to
<code>^[[21~</code>, <code>^[[23~</code>, and
<code>^[[24~</code>. <em><code>Shift-F1</code></em> through
<em><code>Shift-F12</code></em> were used for F13 through
F24, and generated codes from <code>^[[11;2~</code> to
<code>^[[24;2~</code>. Similarly
<em><code>Ctrl-F1</code></em> through
<em><code>Ctrl-F12</code></em> were used for F25 through
F36 and generated codes <code>^[[11;5~</code> to
<code>^[[24;5~</code>, and
<em><code>Ctrl-Shift-F1</code></em> through
<em><code>Ctrl-Shift-F12</code></em> were used for F37
through F48 and generated codes <code>^[[11;6~</code> to
<code>^[[24;6~</code>. None of the base xterm
<code>$TERM</code> 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
<code>OldXtermFKeys</code> resource to 'true'.</p>
</blockquote>
<p>Not only that, but the comment (and much of the page) is
inaccurate. For instance:</p>
<ul>
<li>The X Consortium went out of business late in 1996 (see
<a href=
"http://www.opengroup.org/tech/desktop/Press_Releases/xccloses.htm">
press release</a> from July 1996).
<ul>
<li>The first release of X11R6 was done <a href=
"https://www.x.org/releases/X11R6.1/RELNOTES.TXT">early
in 1996</a> by X Consortium.</li>
<li>I've been working on xterm since before that (see
<a href="#my_history">history</a>).</li>
</ul>
</li>
<li>The X Consortium xterm only knew about function keys up
to <strong>F20</strong>.
<ul>
<li>X11R5 defined only 20 function keys, and xterm used
only those since May 1991.<br>
X11R6 changes to xterm did not take advantage of
additional keys aside from the
<em><code>Insert</code></em> and
<em><code>Delete</code></em> on the keypad.</li>
<li>Further changes by The Open Group through X11R6.6
made no changes to xterm's handling of special
keys.</li>
<li>That came in xterm <a href=
"/xterm/xterm.log.html#xterm_130">patch #130</a>
(2000/3/1), starting with the SCO function-keys
feature.</li>
</ul>
</li>
<li>The X Consortium xterm didn't know about using
<em><code>Shift</code></em> to get F13 through F24.
<ul>
<li>I introduced a similar feature (using
<em><code>Control</code></em>) in <a href=
"/xterm/xterm.log.html#xterm_51">patch #51</a>
(1997/9/15) as the <a href=
"#how2_fkeys"><code>sunKeyboard</code></a>
resource.<br>
I did this to leave <em><code>Shift</code></em> for the
VT220 UDK (user-defined keys).</li>
<li><strong>rxvt</strong> used
<em><code>Shift</code></em>; the key combination was
popular.</li>
<li>Alexander V Lukyanov's changes in <a href=
"/xterm/xterm.log.html#xterm_121">patch #121</a> to
update the terminal descriptions for these keys took
that into account.</li>
</ul>
</li>
<li>The X Consortium xterm didn't know about using
<em><code>Control</code></em> to get F25 through F36.
<ul>
<li>Even with X11R6, the last function key was
<em><code>XK_F35</code></em>.</li>
<li>However, since xterm <a href=
"/xterm/xterm.log.html#xterm_94">patch #94</a>
(1999/3/27), it accepts modifiers (shift, control, alt)
to extend the actual set of keys to generate different
escape sequences.</li>
</ul>
</li>
<li>The escape sequences described all date from 2002
(xterm <a href="/xterm/xterm.log.html#xterm_167">patch
#167</a>).
<ul>
<li>Besides function-keys, there are two other groups
of special keys on the keyboard: cursor and
editing-keypad.</li>
<li>Before then, the "2" and "5" in cursor- and
home/end sequences would be first (before the
semicolon).</li>
<li>By that point, GNOME Terminal and KDE Konsole had
copied the earlier behavior, and failed to follow this
change.</li>
<li>At the time, I preferred the VT220 keyboard (that
does not support modified special keys).</li>
<li>However, the <em>app-defaults</em> file which I
provided with xterm did not set the
<code>sunKeyboard</code> resource to do this.<br>
Packagers routinely altered the recommended
configuration, so this difference was not noticed for a
while.</li>
<li>In response to a <a href=
"https://bugzilla.redhat.com/show_bug.cgi?id=122815">bug
report</a>, I switched to the Sun/PC keyboard, using
the <a href=
"/ncurses/NEWS.html#t20040717">xterm-pc-fkeys</a>
building blocks in ncurses' terminfo description for
xterm.</li>
</ul>
</li>
<li>The X Consortium xterm had incomplete support for VT100
keypad.
<ul>
<li>I added a resource <code>sunKeyboard</code> to tell
xterm to look at other keyboards to simulate the
keypad.</li>
<li>To do this, I made F1 through F4 act like the VT100
PF1 through PF4.</li>
<li>That came in xterm <a href=
"/xterm/xterm.log.html#xterm_79">patch #79</a>
(1998/6/28).</li>
<li>Not everyone liked that, so I added another
resource to allow turning off the change to F1 through
F4.</li>
<li>Actually <code>OldXtermFKeys</code> is the resource
<em>class</em>; the actual resource is
<code>oldXtermFKeys</code>.</li>
</ul>
</li>
</ul>
<p>By the way, although The Open Group made changes, none of
those have been incorporated in this version of xterm. That
was intentional (see <a href=
"https://invisible-island.net/personal/copyrights.html">discussion</a>).
Consequently, the xterm copyright makes no mention of The
Open Group.</p>
</li>
</ul>
<h2 id="future_work-id"><a name="future_work" id=
"future_work">Ongoing/future work</a></h2>
<ul>
<li>soft (downloadable) fonts</li>
<li>printer interface
<p>Done, except for the corresponding support in the VT52
emulation. It would be nice to have a dialog to control
this.</p>
</li>
<li>allow alternate libraries for popup-menus and dialogs
<p>My configure script currently provides tests for the
variations of Athena widgets (Xaw3D, neXtaw). I intend to
make additional changes to support <a href=
"xterm.faq.html#bug_mxterm">Motif scrollbars and menus</a>.
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).</p>
</li>
<li>popup window that shows hex code for content of a character
cell and hexadecimal keyboard entry for all Unicode characters
(ISO 14755)</li>
<li>correct cut&paste of TAB character</li>
</ul>
</body>
</html>
Zerion Mini Shell 1.0