[rescue] Silly NetBSD question

[Joshua D Boyd]

On Mon, Nov 19, 2001 at 06:43:15PM -0500, Greg A. Woods wrote:
> 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.

OK.  When I say that man wasn't working correctly, I mean that it wasn't 
erasing old lines before printing new lines on top.  Further, it would print 
the man page to the bottom of the page, then it would draw the status bar
several lines up from the bottom, obliterating the line there before.  

This is with Minicom 1.83.1.  Minicom is in vt102 mode.  There doesn't appear 
to be a vt100 mode.  On the upside, c-kermit works perfectly.  Now that I have
it enabled, telnet works perfectly.  So, after completing this message, I
intend to remove minicom (I don't like leaving software installed that I don't
use).
 
> 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.

Perhaps it is vt emulation bugs.  I don't know, and now that I have a workable
solution, I don't really care.
 
> C-Kermit, like 'cu' just passes all data directly through to your
> terminal unchanged.

I think that is the action I would generally prefer.
 
> >  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.

What do I do if I am told terminal type unknown by programs on the client 
system?  In the past, I just set the login script to check if it is the
unknown type (for instance, default irix 6.2 doesn't seem to know about rxvt)
and if so, set it to something that appears to work fine (usually either xterm
or vt100).
 
> If so then perhaps you might try using 'cu' instead of kermit or
> minicom.

Is there any particular advantage to cu over kermit?  I hate installing large 
packages if I don't use most of it.
 
> > 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.)

Cool.


-- 
Joshua D. Boyd