Trying to get termcap entry for xterm for CtC
Boyd Lynn Gerber
I have a client that uses CtC. They orignally were using this with XENIX
and SCO UNIX 3.2v4.2. It uses Cadol and INFORMIX. Below is the file from
their termcap.note. Is there any documentation somewhere that I can use
to create a valid termcap for xterm for this software?
Thanks,
--
Boyd Gerber <ger...@zenez.com>
ZENEZ 1042 East Fort Union #135, Midvale Utah 84047
--------------------------termcap.note------------------------------
CtC Uses The Following Termcap Entries
Terminal Control Mnemonics
Mnemonic Description
AZ Non-embedded attributes
AP Only a protected att is non-embedded
AG Att zero clears the graphics mode. (SCO UNIX ansi)
xw Don't repaint attributes to last character of screen
GP Graphics are displayed in protected mode
ic Insert a character
dc Delete a character
al Insert a line
dl Delete a line
cm Cursor positioning
bl Bell
po Slave printer on
pf Slave printer off
PS Print screen out aux port
If this mnemonic is defined then it is echoed when the print
screen function key is pressed.
ce Clear to end of line
cl Clear screen
Cu Clear unprotected fields to end of screen
Note: If the terminal does not support protected characters
adequately then don't define the 'Cu', 'Cc', 'Co', or 'Cf'
mnemonics. The runtime will emulate protected fields.
So Begin display to status line
Sf End display status line
Keyboard Control Mnemonics
Mnemonic Description
kH Help key
kl Left arrow key
kr Right arrow key
ku Up arrow key
kd Down arrow key
kh Home key
Kk Keyboard Lock
Kf Keyboard free
Kp Print Screen
Function Keys:
k0 F1
k1 F2
k2 F3
k3 F4
k4 F5
k5 F6
k6 F7
k7 F8
k8 F9
k9 F10
kA F11
kB F12
kC F13
kD F14
kE F15
kf Page Down
kg Page Up
ke End
ki Insert
kj Delete
Attribute Mnemonics
Mnemonic Description
Define either Cc or Co and Cf.
Cc Bit field which is ORed with the last character of the att
for protected atts.
Co Start protected characters
Cf End protected characters
A0 Normal
A1 Dim
A2 Inverse
A3 Inverse and Dim
A4 Blinking
A5 Blinking and Dim
A6 Blinking and Inverse
A7 Blinking and Inverse and Dim
A8 (not used but required entry for now)
Graphics Mnemonics
Note: In cases of two mnemonics having the same description, the first is normal display and the second is bold display.
Mnemonic Description
GS start graphics mode
GE end graphics mode
GH horizontal line
Gh horizontal line
GV vertical line
GC intersection
Gc intersection
GU up tick
Gu up tick
GD down tick
G3 lower left corner
G6 lower left corner
G2 upper left corner
G7 upper left corner
G1 upper right corner
G5 upper right corner
G4 lower right corner
G8 lower right corner
GR right tick
Gr right tick
GL left tick
Gl left tick
--------------------------termcap.note------------------------------
Brian K. White
First you have to decide which exact xterm client you are going to use and
only use it across the board, and accept the fact that most others will not
work perfectly.
Probably the xfree/xorg xterm is what you want and thats what I'll talk
about now, but just be aware there are ...
# grep "^xt" /etc/termcap |wc -l
40
... at least 40 variations of "xterm" program, all of which would by default
just call themselves "xterm" in the TERM variable
more than that really since that grep didn't get konsole, gnome, kvt, Eterm,
rxvt, etc...
Sco's xterm behaves different from xfree's, from, ibm's, from sun's, from
hp's, from sgi's etc...
So "xterm" is about as useful as "ansi" as a specification. (not at all
useful)
I deal with that by using rxvt everywhere and specifying "rxvt" in the TERM
variable instead of "xterm". There are rxvt binaries for sco and everything
else, and it's painless to add rxvt termcap & terminfo to sco boxes because
it never already exists there, and linux/freebsd boxes usually already have
it at least after you install the rxvt package. That way I don't have one
persons "konsole" and a sco box's "xterm" and a freebsd box's "xterm" all
trying to use the same termcap entry called "xterm", and having that entry
be not good enough except for the freebsd guy. PuTTY has a rxvt mode too so
that covers windows clients. (PuTTY can also be configured to emulate SCO,
Linux and Freebsd consoles directly so I don't actually usually use putty in
rxvt mode) rxvt is also available on windows via cygwin but I wouldn't
consider that a very handy way to get a terminal emulator.
But assuming you want to center on the xterm that comes in the current
version of xfree/xorg as your standard instead of rxvt or others, your
reference material is:
xfree's official description of it's xterm:
http://www.xfree86.org/current/ctlseqs.html
The existing termcap entries for xfree's xterm:
/etc/termcap on a linux or freebsd box.
/usr/X11R6/lib/X11/etc/xterm.termcap on a linux/freebsd box
Definition of standard termcap field names:
"man 5 termcap" on a linux box.
You may have to install a package named termcap before this even exists.
"man F termcap" on a sco box.
Describes some codes not seen elsewhere.
Definition of your apps special termcap field names:
The document you posted above.
Note that this app expects some termcap field names which conflict with
standard termcap files.
This means that while using the new special termcap entry, only this app
will work correctly.
If you system()/shell out to some other app, like print to screen that uses
"less" for one example, that child app won't work perfectly, because, fior
example, while your app expects termcap field kD to mean F14 (shift-F2),
every other app on the system will interpret kD to be the Delete key. This
app want to use kj for the delete key, meanwhile every other app will not
recognize the field named kj and just ignore it. Maybe this won't matter.
Maybe you can get around it by giving the new entry a special name like
xterm-ctc an playing careful games with the TERM variable in the apps start
script and in /etc/profile, ~/.profile, /etc/kshrc, /etc/bashrc, etc... so
that TERM switches back to "xterm" whenever it's not actually in the CtC
app.
The first thing I'd do is see what working terminal entries you may already
have that are close to xterm.
That means vt100.
If you have a working vt100, vt102, etc.. vt-anything thats 90% of xterm
already and all you probably have to do is redefine some of the F-keys and
resolve the discrepencies between CtC and standard like kA to kE, ke & kj,
throw away some of the fields from the standard one like AL DC DL DO IC
I took a stab at making the new termcap
I manually clipped out the "xterm-new" entry from my /etc/termcap into a
seperate file termcap.xterm so I could generate a one-cap-per-line listing
on paper thats easier to go over one code at a time and check them off and
translate into the equivalent codes from the CtC docs.
tr -d "\n" < termcap.xterm |tr ":" "\n" |lp
And printet your email so I could check off items from there too.
Some of it came from my filePro termcap for rxvt/xterm
The G* fields expect a cp437 character set.
roughly the process was:
read a code from the standard entry: k1=\EOP
look up k1 in "man 5 termcap" on linux and/or "man F termcap" on sco
see that normally k1 means F1
try to find F1 in the CtC doc
see that CtC uses k0 for F1
write k0=\EOP to the new termcap
repeat...
Some codes I just dropped. Example, AL=\E[%dL in the standard termcap has no
analog in the CtC doc and doesn't seem terribly important anyways.
Some codes transfer without changing. Example al=\E[L exists in the standard
termcap, and exists and has the same meaning in the CtC doc.
Some codes are radically different in CtC from strandard so the code goes
into the new termcap under some other name than it was in the standard.
Example:
kD is delete key in the standard termcap, but it needs to be F13 in the new
termcap.
Meanwhile CtC uses kj to define the delete key.
Meanwhile the standard termcap (meaning the termcap/terminfo/curses
libraries, meaning all other apps on the system) doesn't regognize kj at
all.
Standard :: CtC
kD=\E[3~ :: kD=\E[25~
[nohing] :: kj=\E[3~
@7=\E[4~ :: ke=\E[4~
ke=\E[?1l\E> :: [nothing]
I came up with this for starters.
This doesn't define everything mentioned in the ctc doc, nor everything
thats in the standard xterm termcap,
but everything here is in the ctc doc:
xterm-ctc|Special xterm for CtC
:al=\E[L:bl=^G:ce=\E[K:cl=\E[H\E[2J:cm=\E[%i%d;%dH:dc=\E[P:dl=\E[M:\
:kl=\EOD:kr=\EOC:ku=\EOA:kd=\EOB:kh=\EOH:kj=\E[3~:ke=\E[4~:ki=\E[2~:\
:kf=\E[6~:kg=\E[5~:k0=\EOP:k1=\EOQ:k2=\EOR:k3=\EOS:k4=\E[15~:\
:k5=\E[17~:k6=\E[18~:k7=\E[19~:k8=\E[20~:k9=\E[21~:kA=\E[22~:\
:kB=\E[23~:kC=\E[24~:kD=\E[25~:kE=\E[26~:pf=\E[4i:po=\E[5i:PS=\E[0i:\
:GS=\E[12m:GE=\E[10m:GV=\263:GH=\304:G1=\277:G2=\332:G3=\300:G4=\331:\
:GU=\301:GD=\302:GC=\305:GR=\303:GL=\264:\
:A0=\E(B\E[m:A1=\E[1m:A2=\E[7m:A3=:A4=\E[5m:A5=:A6=:A7=:A8=:
This leaves out a bunch of common things that are in the standard termcap
for most terminals, not just xterm. The ctc doc says it only uses the codes
it mentions so the codes I left out shouldn't matter except to other apps.
But in case above doesn't work you can try adding this to above. Remember to
add a trailing backslash to the last line above.
These are things that are in the standard termcap, that don't actually
conflict with the ctc docs:
:am:bs:km:mi:ms:xn:co#80:it#8:li#25:bt=\E[Z:cd=\E[J:cr=^M:do=^J:\
:ei=\E[4l:ho=\E[H:im=\E[4h:is=\E[!p\E[?3;4l\E[4l\E>:kb=^H:le=^H:\
:nd=\E[C:rc=\E8:sc=\E7:se=\E[27m:sf=^J:so=\E[7m:ta=^I:up=\E[A:
That also sets lines to 25 to better emulate a console or serial terminal so
remember to use "-geometry 80x25" on the xterm command line arguments.
I was lazy and didnt figure out the proper ANSI for A3, A5, A6, A7 either.
If you have a working entry for ansi, scoansi, or vt-anything you should be
able to copy them right out of that.
good luck
Brian K. White -- br...@aljex.com -- http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
Bela Lubkin
[bunch of great termcap stuff]
> Note that this app expects some termcap field names which conflict with
> standard termcap files.
> This means that while using the new special termcap entry, only this app
> will work correctly.
> If you system()/shell out to some other app, like print to screen that uses
> "less" for one example, that child app won't work perfectly, because, fior
> example, while your app expects termcap field kD to mean F14 (shift-F2),
> every other app on the system will interpret kD to be the Delete key. This
> app want to use kj for the delete key, meanwhile every other app will not
> recognize the field named kj and just ignore it. Maybe this won't matter.
> Maybe you can get around it by giving the new entry a special name like
> xterm-ctc an playing careful games with the TERM variable in the apps start
> script and in /etc/profile, ~/.profile, /etc/kshrc, /etc/bashrc, etc... so
> that TERM switches back to "xterm" whenever it's not actually in the CtC
> app.
This is unlikely to be a problem on most modern systems, including OSR5.
All of the system-provided apps, and anything you're likely to compile
or build from open source, uses terminfo. Only really old commercial
apps use termcap.
Also, most (but not all) commercial apps that use termcap will look
first to a private file (e.g. /usr/lib/oldapp/termcap) before the system
termcap file. The "termcap.note" that Boyd posted regarding "CtC"
doesn't mention filenames, but there's a good chance it has a private
file even if it will also look to /etc/termcap. Look among its private
files for likely candidates; experiment by e.g. adding a new entry under
a false name, then running the app with TERM=that false name. Does it
emit the codes you told it, or does it complain there's no such
terminal?
You may also be able to find the private file by running `strings` on
its binaries (and possibly shared libraries, but probably not if it
originally ran on Xenix).
Even if there is no private file, the fact that hardly anything uses
termcap any more allows you to do just about anything you want with the
termcap entry.
>Bela<