[comp.sys.sun] curses sets terminal to 7-even

davidb@uunet.uu.net (David Barts) (10/08/90)

I write:
> I have noticed something very annoying about curses on SunOS 4.0.
> If I have a terminal set for 8 bits, no parity, and run a program
> that uses curses (more(1), for example), the terminal gets reset
> to 7 bits even....

Guy Harris (auspex!guy) responded via E-mail:
> . . .Incorrect setting of "8 bits, no parity", most likely.
> 
> Try doing "stty pass8" or "stty cs8 -parenb -istrip" rather than "stty
> cs8 -parenb", for example.  If the program is using the BSD-environment
> "curses", it's using the BSD-flavored "ioctl"s, and the *only* time
> those "ioctl"s recognize a tty as being in 8-bit mode is if:
> 
> 1) the character size is 8 bits per character ("cs8");
> 
> 2) parity is not enabled ("-parenb");
> 
> 3) *INPUT* isn't being stripped to 7 bits ("-istrip"). . .
                                              ^^^^^^^

BINGO!  I hadn't done this, just "stty cs8 -parenb" (actually, getty and
login had, which is a story we'll get into later). Doing "stty -istrip"
fixes the problem.  Thanks!

But if only it were that simple.  I did not set the line for 8 bits, no
parity; I depended on getty(8) do do that for me, using the gettytab
entries:

0|d300|Dial-300:\ 
:nx=d1200:p8:sp#300: d1200|Dial-1200:\
:nx=d2400:p8:sp#1200: d2400|Dial-2400:\ 
:nx=d300:p8:sp#2400: 

The gettytab(5) man page for OS/MP says that p8 is a Boolean flag which
means "terminal uses 8 bits, no parity."

To make a long story a little shorter, after about six hours of
experimentation today I have found that the p8 flag *does* cause getty to
set the terminal correctly (-istrip and everything).  But login(1)
apparently decides to take the liberty of setting the ISTRIP bit :-(.
This can be demonstrated conclusively by writing a shell script called
/usr/local/bin/login:

	#!/bin/sh
	stty -a
	exec /usr/bin/login $@

(Then add lo=/usr/local/bin/login to the gettytab entries for the line.)
Before login is exec'ed, the terminal is as it should be, but afterwards,
ISTRIP has been set.  This has been demonstrated on accounts with both sh
and csh, as well as a special account I created that runs a C program that
does an execl of stty -a as its login shell.  In all cases ISTRIP is not
set before login runs, and is set afterwards.  So it looks like a login
bug.

I have informed Solbourne of this and will report to the net if I get any
more updates on this.

David Barts			Pacer Corporation, Bothell, WA
davidb@pacer.uucp		...!uunet!pilchuck!pacer!davidb