Standard Terminal Sizes?

[A. Daniel King_1]

It seems that vt100-vt220 are the most common standards among terminal clients. I was wondering if there were larger *column* standards -- for instance, I 80 and 132 columns seem to be standards for the vts. Is there a widely-recognized 200 column standard? Using a typical terminal emulator (Putty, SecureCRT, Anzio, name it), would it be "normal" to see something besides 80 or 132 columns as a standard?

I'm interested in interfacing with HP-UX, but also with Linux, and it feels like I've outgrown 132 columns ...

[spex]

I'd never heard of a standard supporting more than 132 columns, but some Googling revealed:

http://www.seagullsoftware.com/products/bluezone/faq/emulation-faq.html

Under TN3270/TN3270E screen sizes:
Model 3290 (62 x 160)

So it may be possible in general, although I'm not sure if it would work under HP-UX.

[H.Merijn Brand (procura]

It's only a virtual limit. xterm's on X11 are only limited by the size of your desktop. I've quite often used *tiny* fonts, just to be able to see the width I needed.

Just tested that on my 22" LCD, and got to a readable workable xterm of 314 columns.
With the smallest font I've configured available for my xterms here on my laptop, I get to 250 columns and 105 visible lines (scrollback stores 5000 more), which I use *very* often, for example to review the statistics I post here.

Enjoy, Have FUN! H.Merijn

[A. Daniel King_1]

Thanks for the quick response!

As far a X, I've still got to fix my recent Cygwin update -- some bits, including X were quite broken.

Just looking at terminfo on the two machines in front of me ...

HP-UX 11i:

$ ll -d /usr/lib/terminfo/*/* | wc -l
1827
$ ll -d /usr/lib/terminfo/*/* | grep 3270
$ ll -d /usr/lib/terminfo/*/* | grep 3290

Ubuntu 5.10 (Breezy Badger):
$ ll -d /lib/terminfo/*/* | wc -l
35
$ ll -d /lib/terminfo/*/* | grep 3270
$ ll -d /lib/terminfo/*/* | grep 3290

There seem to be some more limited options under Ubuntu, and neither seem to have 32[79]0.

[H.Merijn Brand (procura · Accepted solution]

Neither does HP-UX 10.20, HP-UX 11.00, HP-UX 11.23, AIX 4.3.3, AIX 5.2.0, or SuSE Linux 10.0, but that doesn't mean it cannot exist.

I ran the attached script on my SuSE box, and it shows a lot of non-comforming (if you see 80/132 as conforming) terminal defenitions.

--8<---
#!/pro/bin/perl

use strict;
use warnings;

use File::Find;

my %t;
find (sub {
-f or return;
-l and return;
my $term = $_;
local @ARGV = ("infocmp $term |");
while (<>) {
m/^(\w.*)/ and $t{$term}{nm} = $1;
m/\bcols#(\d+)/ and $t{$term}{cl} = $1;
}
}, "/usr/share/terminfo");

foreach my $term (sort keys %t) {
printf "%5d %-16s %s\n", $t{$term}{cl} // 0, $term, $t{$term}{nm} // $term;
}
-->8---

Here's the tail of that list, when piped through sort -n:

144 xnuppc+144x48 xnuppc+144x48|Darwin PowerPC Console 144x48 support (1152x768 pixels),
160 rt6221-w rt6221-w|Ramtek 6221 160x48,
160 xnuppc-160x64-m xnuppc-160x64-m|darwin-160x64-m|Darwin PowerPC Console (monochrome) 160x64,
160 xnuppc-160x64 xnuppc-160x64|darwin-160x64|Darwin PowerPC Console (color) 160x64,
160 xnuppc+160x64 xnuppc+160x64|Darwin PowerPC Console 160x64 support (1280x1024 pixels),
178 guru-76-w guru-76-w|guru 76 lines by 178 cols,
178 guru-76-wm guru-76-wm|guru 76 lines by 178 cols with 255 cols memory,
178 guru-76-w-s guru-76-w-s|ann arbor guru/76 lines+status+wide,
200 xnuppc-200x64-m xnuppc-200x64-m|darwin-200x64-m|Darwin PowerPC Console (monochrome) 200x64,
200 xnuppc-200x64 xnuppc-200x64|darwin-200x64|Darwin PowerPC Console (color) 200x64,
200 xnuppc+200x64 xnuppc+200x64|Darwin PowerPC Console 200x64 support (1600x1024 pixels),
200 xnuppc-200x75-m xnuppc-200x75-m|darwin-200x75-m|Darwin PowerPC Console (monochrome) 200x75,
200 xnuppc-200x75 xnuppc-200x75|darwin-200x75|Darwin PowerPC Console (color) 200x75,
200 xnuppc+200x75 xnuppc+200x75|Darwin PowerPC Console 200x75 support (1600x1200 pixels),
256 xnuppc-256x96-m xnuppc-256x96-m|darwin-256x96-m|Darwin PowerPC Console (monochrome) 256x96,
256 xnuppc-256x96 xnuppc-256x96|darwin-256x96|Darwin PowerPC Console (color) 256x96,
256 xnuppc+256x96 xnuppc+256x96|Darwin PowerPC Console 256x96 support (2048x1536 pixels),
32767 citoh-prop citoh-prop|citoh-ps|ips|citoh in proportional spacing mode,

Enjoy, Have FUN! H.Merijn

[Bill Hassell]

The prehistoric DEC VT series have become the defacto standard for terminal emulators. However, the term 'standard' is almost laughable as there are hundreds of emulators claiming some VT compatibility yet allow for hundreds of columns and hundreds of rows, none of which are 'compatible' with (now museum pieces) real VT terminals. Since the vast majority of Unix admins have never touched a DEC VT terminal, here is the best link in the known universe for the VT series:

http://vt100.net/

It really does not matter whether your terminal is set to 132, 150, 200 or more columns. If your favorite menu application was never written to handle variable screen measurements, all you'll get is a mess. Now the good news for HP-UX users is that not only is there a great terminal independent API library called curses, but HP has created a great terminal identifier called ttytype. (note: tset is deprecated)

Now the reason a terminal identifier is so important is that your systems can't guarentee that every user will login with the same terminal emulator. (I'll refer to emulators because almost no modern system uses 'real' glass terminals these days) And worse, each emulator is configurable, from escape sequence options to screen dimensions.

The WORST thing you can do as an adminstrator is to hardcode TERM, COLUMNS and LINES. And the second worst thing is to allow /etc/profile to bypass ttytype if TERM is already set. You absolutely want to test the terminal and set the 3 critical values at every login. Unfortunately, the standard HP-UX /etc/profile assumes that telnet negotiations will preset these variables correctly and bypass ttytype. This ONLY works if you never use PCs, never use Linux and never use a non-HP-UX system for your emulation.

Since this is totally impractical, all /etc/profile files should be modified to always query the terminal. Here is the standard code in /etc/profile:

> if [ "$TERM" = "" -o "$TERM" = "unknown" -o "$TERM" = "dialup" \
> -o "$TERM" = "network" ]
> then
> eval `ttytype -s -a`
> fi
>
> export TERM
>
> # set erase to ^H, if ERASE is not set
> if [ "$ERASE" = "" ]
> then
> ERASE="^H"
> export ERASE
> fi

All that code will do is to use whatever the remote emulator (actually, the telnet client) thinks is the current terminal and screen dimensions. FOr instance, some Linux variants will report TERM=linux which is very strange because linux never manufactured a terminal nor does it define a terminal standard -- it is an OS with many variations and possible emulator choices. Naturally, there is no way to associate this TERM value with a terminal or emulator.

For completeness, I do have to mention tic and untic which allow you to create terminfo entries for anything...read the man pages.

So the above /detc/profile code should be replaced with:

eval $(ttytype -s)

--for csh users, replace the line:

> if ( ! $?TERM ) then # if TERM is not set,
> setenv TERM hp # use the default
> endif

with:

eval ttytype -s

Now as to COLUMNS and LINES:

When you login with a noe-standard screen dimension (typically 24x80), the ttytype command will set the values automatically. However, since the days of 9.0, the special telnet signal SIGWINCH (window change) will update COLUMNS and LINES automatically. BUT *only* if the client side OS (PC, Linux, etc) *AND* emulator is smart enough to send this telnet code:

http://www.faqs.org/rfcs/rfc1073.html

So with some terminal emulators, you can set a new screen size and HP-UX will see this new setting. Some emulators (especially Xwindows) will trigger SIGWINCH whenever you resize the window. (see man 5 signal, and man termio) Note: there is a deprecated command: resize which sort-of emulates ttytype but was designed primarily for Xwindows and csh. If your emulator+OS does not change LINES and COLUMNS, then just type: eval $(ttytype -s) whenever you change the window size. An alternative is to alias this to something simple like:

alias rs='eval $(ttytype -s)'

Then just type: rs whenever you change window size.

Now all of this is background for the question. But the real answer is: use whatever you can see on the screen (90x300 for example) and all will work OK as long as the application understands TERM, COLUMNS and LINES. An application that really works well with a proper TERM COLUMNS LINES setting is vi.

[A. Daniel King_1]

This will particularly stick in my mind:

"If your favorite menu application was never written to handle variable screen measurements, all you'll get is a mess."

Which I'd like to take as, "If you're writing a terminal-aware program, be prepared to handle variable measurements."

[Bill Hassell]

"If you're writing a terminal-aware program, be prepared to handle variable measurements."

which is more completely decribed as: Use terminal independent libraries (ie, curses) and never hardcode ANY escape sequence to accomplish a particular control. The man page for tput (and terminfo) is a great resource for shell scripters writing menu programs.

[H.Merijn Brand (procura]

As a side note: 'ttytype' is a *GREAT* program, but unfortunately, HP has not open-sourced it, and it *ONLY* is available (read as "work on"), so you do not have it on AIX for example. So down the drain with portable scripts that (try to) use ttytype.

Now it *is* possible to write it yourself, but it is NO fun!

HP, please open-source it!

instead of curses, GNU gives us ncurses, which is even more portable

Enjoy, Have FUN! H.Merijn

[Bill Hassell]

I agree. ttytype was written more than 15 years ago and has changed relatively little over the years. There is one change that was made that I completely disagree with -- ttytype performs *NO* terminal query on 11i (and I think later versions on 11.00) if the terminal connection is to the GSP/MP. Instead, ttytype forces TERM COLUMNS and LINES to a preset value depending on the GSP/MP settings for terminal settings. This is the one fault in ttytype but since it involves both the OS and a completely different division that works on the GSP/MP firmware, I don't think it will be fixed.

But as most senior sysadmins spend very little time on the console (or LAN console) using fancy menu programs (let's hear it for command line tools!), it is a minor inconvenience.

It turns out that ttytype could actually be reverse engineered with either a serial analyzer or Ethereal. ttytype groups the hundreds of terminals into 3 main groups: ANSI/DEC-VT, Wyse and HP. The ID process involves sending an automated query escape sequence and waiting for one second for a reesponse. If none, the next emultion (Wyse) is tried and again if no response, then an HP terminal query is done. That's why you see a couple of characters (ie, . and .c) on the screen.

When the terminal responds, the program starts down a table of additional queries. The older the terminal, the less detail comes back. For instance, older HP terminals never replied with a model number (ie, 2645A or 2621P, circa 1975+) but newer terminals (like the 2624A, 2392A and all the 700/xx series) could be queried for their exact model and even features like screen memory, softkey contents and peripherals like printer.

Probably the most valuable part of ttytype source code are the comments. They describe all the convoluted tests for older (or super dumb) terminals.

[H.Merijn Brand (procura]

Bill, you know perfectly well that it is NOT allowed to reverse engeneer ttytype :)

BTW truss/tusc are also a major help here.

5581 Jul 2 2001 ttytype.c

(Don't tell anyone)

Enjoy, Have FUN! H.Merijn