Johnny Billquist wrote:
> 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.

A PuTTY session emulating 'scoansi' on a PC works fine,
as does PTerm doing 'scoansi', but either set as vt100 doesn't
work, so I'd guess that the app is hardcoded to use scoansi
codes, not proper termcap stuff, or it's just not picking them
up because whatever it uses to determine termtype isn't
getting it from the terminal emulator.

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

Once I get a shell on the SCO box that isn't only able to run the app,
so I can test and set $term, I'll be able to do that.  In the mean
time, I'm wondering if I can use screen to do some magic in the same
way that I did 12 years ago with the old AWA box and SunOS 4.
I just can't remember how that was done with screen.

The client doesn't mind if the procedure isn't automagic (although I
can automate screen startup etc in .login, for example) but they do
want it to work :)