Subject: Re: emulating SCO-TERM on NetBSD console?
To: Michael Smith <email@example.com>
From: Johnny Billquist <firstname.lastname@example.org>
Date: 04/25/2007 14:38:09
Changing thing in wscons is not the solution. That don't change the
behaviour of the console. It tells NetBSD what the behaviour of the
console is, so that NetBSD can do the right thing.
What we first of all would need to know is what the "dumb" terminal
really was. Using the word "dumb" is misleading, since it's not dumb in
a way that is relevant here. It's a smart terminal, that understands
some form of control sequences to do specific things.
You need the NetBSD console to work the same way as that "dumb"
terminal. You can select between a couple of different behaviours of the
console when you build the NetBSD kernel, but not many.
However, you might be lucky enough that the SCO server is a clever
enough unix system, and the application clever enough to be written with
termcap (using curses for instance). If so, you can tell the SCO server
what kind of terminal you are now using, and by telling it that you're
on a terminal of the kind that the NetBSD kernel uses for console, you
should become much happier.
Michael Smith wrote:
> On Wed, 25 Apr 2007 21:54:30 +1000
> Carl Brewer <email@example.com> wrote:
>>This is more a general UNIX question than NetBSD
>>specific, but one of the boxes is NetBSD, and maybe someone
>>here has a suggestion :
>>I have a client with an ancient SCO server running their
>>main business app (it's a database in postgres or something,
>>it's their whole business ...).
>>They had a couple of old dumb terminals hooked up to it via
>>serial lines, and some new PCs running PTERM or some other
>>telnet client on win32 that connect to it and they work - except
>>their last dumb term just died, so I figured I could hook up
>>a NetBSD box and make that emulate a dumb terminal (they don't
>>want to run win32 unless they have to).
>>To cut a long story short, the PC is running NetBSD 3.1 and
>>no X11, just a generic PC console. I can (as you'd expect)
>>telnet from it to the SCO server and get a session running and
>>it mostly works, except that function keys don't seem to get
>>through, and screen fields in their application get filled out
>>with control chars etc when they type. ie: there's something
>>wrong with the terminal emulation. The PC's running win32 are
>>emulating 'sco-term' using a telnet client called PTerm and they work
>>just fine, but telnet (and rlogin, I thought maybe 8 bit was needed,
>>but telnet -8 did the same thing too) from the NetBSD box fails.
>>The app is running a text UI that looks like it's written in
>>curses or similar. If I didn't know better I'd have sworn it
>>In the long distant past I solved a similar problem connecting
>>to an old PICK box (McDonnell-Douglas/AWA something running 'reality',
>>for the curious) by wrapping the login in a screen session, which
>>took care of a lot of key mapping etc, but I can't remember how I
>>Does anyone here have any suggestions for how to get the NetBSD
>>console on a PC to correctly work as a telnet client to this
>>old SCO server that doesn't seem to grok vt100 or pcvt?
>>Can I maybe set /etc/tty's for 'console' to be sco-term or
>>similar? or will that break the console?
> I don't claim to have the whole answer however:
> console "/usr/libexec/getty Pc" vt100 on secure
> ttyE0 "/usr/libexec/getty Pc" vt220 off secure
> ...and so on.
> According to the man page the type field "vt100" is defined by the termcap file:
> Which includes:
> # SCO console and SOS-Syscons console for 386bsd
> # (scoansi: had unknown capabilities
> # :Gc=N:Gd=K:Gh=M:Gl=L:Gu=J:Gv=\072:\
> # :GC=E:GD=B:GH=D:GL=\64:GU=A:GV=\63:GR=C:
> # :G1=?:G2=Z:G3=@:G4=Y:G5=;:G6=I:G7=H:G8=<:\
> # :CW=\E[M:NU=\E[N:RF=\E[O:RC=\E[P:\
> # :WL=\E[S:WR=\E[T:CL=\E[U:CR=\E[V:\
> # I renamed GS/GE/HM/EN/PU/PD/RT and added klone+sgr-dumb, based
> # on the :as:=\E[12m -- esr)
> scoansi|SCO Extended ANSI standard crt:\
> So could you put scoansi as a terminal type in /etc/ttys ?
> (cross fingers, its really just a guess).