9296 lines
368 KiB
HTML
9296 lines
368 KiB
HTML
<!--
|
|
*****************************************************************************
|
|
* Copyright 1997-2018,2019 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.378 2019/01/27 17:42:38 tom Exp $
|
|
-->
|
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01//EN">
|
|
|
|
<html>
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Linux (vers 25 March 2009), see www.w3.org">
|
|
|
|
<title>XTerm – Frequently Asked Questions (FAQ)</title>
|
|
<link rev="MADE" 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>
|
|
</head>
|
|
|
|
<body>
|
|
<hr>
|
|
|
|
<p><a href="/">http://invisible-island.net/</a><a href=
|
|
"./">xterm/</a><br>
|
|
Copyright © 1997-2018,2019 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>
|
|
|
|
<h3 id="pre_history-id"><a 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>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.</p>
|
|
|
|
<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 id="my_history-id"><a 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>.</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>
|
|
|
|
<h3 id="forward_history-id"><a 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">1999</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=
|
|
"ftp://ftp.invisible-island.net/xterm/xterm.tar.gz">current
|
|
source (ftp)</a></li>
|
|
|
|
<li><a href="/datafiles/release/xterm.tar.gz">current source
|
|
(http)</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 control sequences document lists a few controls which
|
|
xterm does not (completely) implement, e.g.,</p>
|
|
|
|
<ul>
|
|
<li>key-repeat</li>
|
|
|
|
<li>enabling LEDs other than scroll-lock</li>
|
|
</ul>
|
|
|
|
<p>None of the other terminal emulators implements those
|
|
either.<br></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 (as of September
|
|
2013, it implements 546 of 556 documented controls); the other
|
|
programs change far more slowly, adding only one to konsole. 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=
|
|
"http://www-personal.une.edu.au/~oahlefel/">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="#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_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_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=
|
|
"ftp://ftp.invisible-island.net/xterm/koi8-term">sample
|
|
script</a> and <a href=
|
|
"ftp://ftp.invisible-island.net/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 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_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 am 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>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. Reducing that
|
|
to a single byte allowed a similar scheme using a 4x4x4 cube and
|
|
a proportionately shorter grayscale ramp.</p>
|
|
|
|
<p>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>Finally, in 2012 (<a href="/xterm/xterm.log.html">patch
|
|
#282</a>), I extended the parser to accommodate the "correct"
|
|
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>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>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>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>
|
|
|
|
<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 do 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 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 is a frequently-reported problem
|
|
for Ubuntu users. With other systems, it can occur (as of
|
|
September 2012), but is less frequent. But it has been an issue
|
|
with Ubuntu since 2008.</p>
|
|
|
|
<p>There are 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 is not in xterm, all I can do is to help
|
|
forward those bug-reports to whatever package owns
|
|
<code>compiz</code>. What these have in common is that someone
|
|
has written code which is tested against only a small subset of
|
|
the X protocol.</p>
|
|
|
|
<p>Looking for solutions (since compiz is not being fixed), it is
|
|
possible to disable compiz. The means for doing this vary with
|
|
time. Aside from pointing to the root cause of the problem, there
|
|
is little advice that is useful.</p>
|
|
|
|
<ul>
|
|
<li>For instance, <a href=
|
|
"http://force.subcritical.org/xterm_under_compiz/">this
|
|
comment</a> by Eric Williams suggests that the problem can be
|
|
worked around by setting xterm's <code>borderWidth</code>
|
|
resource to zero.</li>
|
|
|
|
<li>other comments suggest turning off the "desktop effects" or
|
|
"animation".</li>
|
|
|
|
<li>On my machines using the default <em>Ubuntu</em> desktop, I
|
|
can see misbehavior easily in Ubuntu 12.04 using <a href=
|
|
"/vttest/vttest.html">vttest</a>. However, Ubuntu 12.04
|
|
provides <em>Ubuntu 2D</em>, which does not show those
|
|
problems (and is noticeably faster).</li>
|
|
</ul>
|
|
|
|
<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 is 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” persists 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>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 Linux 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>In June 2010, the numbers have 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 depends only on the X11 library.
|
|
As of January 2013, it is in heavy development, and (according to
|
|
comments on its developer's list) growing steadily as the
|
|
developers implement useful features adapted from xterm.</p>
|
|
|
|
<p>For instance, the size counting libraries for st 0.3 on my
|
|
Debian testing machine is on a par with rxvt (and half that of
|
|
xterm, which uses the X Toolkit library).</p>
|
|
|
|
<p>By the way, the page quotes the README file from xterm's
|
|
sources, omitting my editorial comment at the top noting that the
|
|
paraphrase of the opening from Dante's <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 Linux, something is wrong with the resource processing
|
|
(neither popup menus nor colors work).</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 which has been ignored so far (as of
|
|
mid-2012). To work around this (and get useful warnings), I apply
|
|
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>
|
|
|
|
<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=
|
|
"ftp://ftp.invisible-island.net/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#20120211">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: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>
|