Subject: Re: pcvt/tset incompat
To: None <port-i386@NetBSD.ORG>
From: Robert Kennedy <robert@Theory.Stanford.EDU>
List: port-i386
Date: 03/21/1996 11:05:13
> I've a fairly serious problem ...
> If I execute 'tset -s pcvt25h', or simply 'tset -s' when TERM is
> pcvt25h, it seriously mangles my screen...
> My /etc/ttys is correct I think:
> console "/usr/libexec/getty Pc"   pc3     off             # su-console
> ttyv0   "/usr/libexec/getty pcvt" pcvt25h on secure       # multi-console
> ...etc...

Your /etc/ttys is not correct. Either your kernel is built with the
(default) "pc3" console driver, or it's built with the pcvt
driver. One or the other, right? (nd it looks to me like you probably
have pc3 emulation, not pcvt in your kernel.) The terminal types in
your /etc/ttys should be *the same* for console and ttyv0. I bet most
of the trouble you're having just comes from sending the poor pc3
console driver a bunch of (pcvt25h) escape sequences it doesn't
understand.

In multi-user mode, try doing
set term=pc3 (or whatever the appropriate bash syntax is)
tset -s pc3

and see what happens. Look at your kernel config and see which device
driver you're using for the console, and make sure all the lines
corresponding to your screen in /etc/ttys give a terminal type that
corresponds to the driver.

> My TERM envariable has always been set to pcvt25h when on ttyv0, for example.
> But when I execute tset, the whole state gets seriously garbled.  If I do
> it under an xterm, it has the same effect, even if I'm not evaling the
> output...

Yup. Definitely looks like the pc3 emulation in the default driver
can't deal with vt100/vt220 escape sequences in a healthy way.

> vax@linkdead bash$ tset -s pcvt25h
> (clear screen)
> Kill set to :.
>               Interrupt set to #.
>                                  TERM=pcvt25h;
>						TERMCAP='pcvt25h:li#25...(etc)

There is a minor mystery here to me, and that is: Why is OPOST off for
your terminal? OPOST is switched in the tty driver, not the console
driver. So unless the console driver is doing something strange, OPOST
isn't getting switched off by the escape sequences tset sends. Does
bash turn of OPOST and leave it off even when it fork/exec/waits a
child? That seems weird.

	-- Robert Kennedy