Carl Brewer wrote:
> 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.

That kind of information is basically never gotten from the terminal, 
since there is no standard way of getting it.
Normally you either set it in your wscons file, perhaps in /etc/ttys, or 
in some file processed during the login (.login, .cshrc, .profile, 
.shrc, and so on...)

telnet exports the local TERM variable to the remote host. Maybe that's 
why you sometimes might think that hosts "know" what terminal you have.

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

screen is just a program that presents one terminal type to the system, 
and adapts it to whatever terminal type you yourself have. To adapt to 
you, it depends on you setting your TERM variable to a correct value.
To get the remote program to behave correctly, it tries to set the 
remote TERM variable to whatever screen is emulating. If the remote 
program don't care about the TERM variable, or if you can't get it 
exported, then you're depending on that the remote program by default 
assumes the terminal to be of the type screen pretends to be.

You would be helped by being able to get into a shell on the remote system.

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

It all depends on how the different pieces actually work. :-)

	Johnny