[rescue] Silly NetBSD question

[Greg A. Woods]

[ On Monday, November 19, 2001 at 15:51:32 (-0500), Joshua D Boyd wrote: ]
> Subject: Re: [rescue] Silly NetBSD question
>
> OK, I don't know the official terminology.  I am using the rxvt terminal 
> emulater.  Inside it, I was running the minicom terminal emulator, which was
> set to emulate vt102.  After logging into the SS2, I echo $TERM, and it returns
> sun.  If I try to use man, it displays things badly (lines don't cleanly roll 
> off the bottom of the screen, lines that should be at the top appear in the 
> middle, etc.).  Vi does the same thing.  So, I setenv TERM vt100 (I'm using 
> the root default csh). Now vi works correctly, but man still doesn't.

OK, this really shouldn't be that complex.  It's really really simple
from a data communications point of view.  A program sends some bytes
out to whatever you're sitting in front of and they're interpreted and
"displayed" to you.  Any program doing anything more complex than what
'cat' does needs to know how to control the device you're sitting in
front of (because except for the basic core features defined by the ANSI
X3.64 standard, they're all different, even the ones claiming to be
"ansi" terminals).  Generally programs like less, vi, etc., use a
library called "curses" to control your terminal.  There are many
variants of libcurses, and there are at least two major variants of the
terminal capabilities databases used by these libraries: termacap and
terminfo.  (ncurses can use both... :-)

The only thing that might be slightly confusing here is that the meaning
of the names you set TERM to is defined on the system where you set it,
and then the resulting definitions are used to control the device (or
program) you're using.  On NetBSD the specific meanings are defined in
the termcap source file, a copy of which is in /usr/share/misc/termacap.
This file is documented by termcap(5).  (well, actually things can get
more complex if you install any add-on programs that use ncurses or
similar, but the termcap definitions apply for less, vi, etc.)

The most tricky stuff with terminal emulators is ensuring they are
bug-for-bug compatible with the real things.  For example any terminal
emulator claiming to be a real vt100 must implement a number of
undocumented bugs that drastically affect the behaviour of some types of
full-screen programs.  In the M$ world there's only really one "perfect"
terminal emulator, and that's MS-Kermit (C-Kermit's M$-DOS/M$-Win little
brother with a real terminal emulator built into it).  In the X11 world
this is not so much of a problem because there are common termcap
definitions for the most-often used emulators, such as xterm and rxvt.

Another issue with terminal emulators, especially those meant for bitmap
terminals (xterm, rxvt, etc.) is that the number of lines and columns in
your terminal window might be different than what the "real" terminal
might be capable of.  For example on NetBSD the default definition of
the "rxvt" terminal type assumes the window is 24x80.  In fact on *BSD
the size of the terminal is always defined by the current settings
stored in the tty driver.  The termcap default values are only used if
the tty reports zero for either value.  You can see what they are
currently with "stty size" (or "stty -a"), and you can change them with
"stty rows NN columns NN" (or with xterm, by running the standard X11
program "resize", which might work for rxvt too).  Xterm (and rxvt)
normally set the tty size values (and reset them whenever you resize the
window), but nothing can do that across a serial port.

Now what _EXACTLY_ do you mean by "man still doesn't work [correctly]"?
Even with minicom 'man' should work right.  Have you told minicom to
emulate a vt100, or is it still stuck in "Ansi" mode?  Have you told the
NetBSD system that you're using a 24x80 terminal (the default on the
serial console will probably be 24x132, though might be different on a
newer NetBSD)?  If I login on my Sun-SS2 serial console, using a 24x80
xterm with telnet to my terminal server, and even if I do not set the
terminal size correctly, but I do set TERM correctly (i.e. to "xterm"),
everything works OK for "man" despite the fact it thinks my screen is
nearly twice as wide as it really is.

> So, someone suggested C-Kermit.  I gather that this just takes the serial 
> input somehow and passes it to stdio and lets stdio figure out how to display
> it?

Minicom is potentially a really BAD program to use from a terminal
emulation point of view.  Although the latest version claims to pass the
'vttest' tests for vt102 compliance, it's well known for having emulator
bugs.  It's only real advantage is when you're using it to connect to a
non-unix system which only expects a vt102 terminal to be used, and the
termanal you are using doesn't work in the way the target system expects.

C-Kermit, like 'cu' just passes all data directly through to your
terminal unchanged.

>  Meaning that if I use it, instead of setenv TERM vt100, I should perhaps
> use setenv TERM xterm.

Since you're using rxvt, that should be 'setenv TERM rxvt'.

You should always set TERM to a value naming a terminal type suitable
for whatever your terminal is (whether it's a real terminal, or a
terminal emulator), and if it's an emulator always for the *first*
emulation layer from the point of view of the system where you're
setting TERM.

If it's an xterm, then usually "xterm" works (though there are variants
such as "xterm-sun" for when you have the Sun-style function keys
enabled in your X resources).  If you're using rxvt then you should
always set "TERM=rxvt".

You can often get away with "TERM=ansi", though in the PC world this
meaning has been drastically bastardised to imply the stupidly and
incorrectly named minimal "ansi.sys" emulation in the basic M$-DOS
system.  However since the meaning of the names is defined on the
host where you use them, you've got to check the 

>  But, I haven't figured out how to use C-Kermit in this
> capacity (admittedly, total time spent with kermit was about 10mins before 
> deciding to hit the sack).

Do you have GNU UUCP installed on the system you're connecting from?

If so then perhaps you might try using 'cu' instead of kermit or
minicom.

> What about something like cat /dev/ttyS0 to display form the serial port, but 
> what would I send to the serial port?

That's effectively what c-kermit, cu, tip, and similar communications
programs do.  They allow you to control the serial port settings and
they pass the data to/from the port directly to whatever you're
connected with (eg. xterm, rxvt, a real VT-102, etc.)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods at acm.org>     <woods at robohack.ca>
Planix, Inc. <woods at planix.com>;   Secrets of the Weird <woods at weird.com>