[rescue] Silly NetBSD question

[Greg A. Woods]

[ On Monday, November 19, 2001 at 20:31:53 (-0500), Joshua D Boyd wrote: ]
> Subject: Re: [rescue] Silly NetBSD question
>
> 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.  

Hmm -- that's exactly the problem you'll see if you've got a window size
that doesn't agree with the stty settings.  Indeed that's exactly what I
meant by putting the continue prompt somewhere near the middle of the screen.

> 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).

Good to hear!  You've eliminated one layer of emulation translation and
that'll help avoid confusion even if it wasn't the source of your
problem.  You'll still want to make sure you always set the remote
system's 'stty rows XX columns YY' to match your xterm/rxvt window size.

> 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).

That's why I said it's important to realise that the definitions of the
names you use in the TERM variable reside on the host where you use
them.  When you move from system to system you must deterime which
terminal type on the new system is appropriate for your current terminal
(emuulator).  Even common entries such as 'vt100' or 'xterm' are not
necessarily going to cause programs to behave the same on two different
systems.

In some cases you can carry your terminal definition with you.  For
target systems (and/or applications) which use the older termcap style
definitions it's sufficient to pack them into the setting of the TERMCAP
environment variable.  You'll find that 'tset -s' on *BSD will offer up
the correct settings for you.  On newer systems with (and/or
applications using) terminfo style capabilities databases though (which
I assume irix-6.2 is one of), you've got to compile and install the
description file, which you can do as an ordinary user if you point the
TERMINFO environment variable at the root of your private terminfo
database.

On systems with (and/or applications using) ncurses you might have the
best of both the termcap and terminfo worlds in that you can use either
a termcap definition or a terminfo definition,

Most terminfo-based systems come with infocmp, which besides being the
terminfo compiler can also be used to compare similar entries and to
translate definitions between the two formats too.  Terminfo is a great
deal more modern, somewhat more capable, much easier to use and
understand, and generally more efficient than termcap.

In the days before bitmap terminals and consoles every sysadmin had to
have a basic understanding of termcap and/or terminfo and be able to at
least manipulate these databases, if not even to write new entries and
fix bugs in old entries.  These days though when almost everyone does
almost everything on an xterm or similar there are not many people left
who even know why you have to set $TERM!  :-)

> Is there any particular advantage to cu over kermit?  I hate installing large 
> packages if I don't use most of it.

The modern C-Kermit is a big, complex, and quite powerful program, and
it can very relibably transfer files between almost any two kinds of
systems.  It can be used over TCP/IP instead of telnet and ftp too.  It
can be scripted, and it has many settable parameters and options.

'cu' is a simple little program that sets up the serial tty's
parameters, optionally dials a modem, and then connects your session
with a remote connection.  Cu can transfer files, though without any
guarantee of reliability (effectively it just cat's the file into the
sending side, and cat's it back out into the destination file -- no
error checking, not even a checksum).

I almost always use 'cu' and only very rarely ever use kermit, but
that's mostly because I almost always only connect to other unix hosts
and I rarely ever have to transfer files over manual connections.

'cu' usually needs some minimal configuration (which can be shared with
UUCP's ports and modem configurations), but with appropriate privileges
and tty permissions it can be used with no configs just like kermit can.

-- 
							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>