Subject: login and bash on a hardwired terminal.

From: Dale Scheetz <[email-masked]>
Date: Thu, 6 Jun 1996 22:39:10 -0400 (EDT)

Thanks to Dirk and Guy, I got getty running on ttyS1 to a Data General
terminal (ok, ok, but I got it for free. In fact I have 6 of them) but I
still have problems.
Pressing return on the terminal causes getty to put up the login message
and prompt, just as it should. After entering a user name (getty kicks off
login) a short line of garbage that looks like it would like to say
Password but actually says:

P8^w'd

and then moves up to the previous line and prints:

dwarf (the user name)

entering the password for dwarf at this point creates a spew of reverse
video spam across several lines and eventually produces a reverse video
prompt. All input typed at the keyboard from this point on is reverse
video. Anything that I type is displayed ok on the terminal. Anything that
bash returns to the terminal is hopeless garbage. 

I have tried several terminal types (setting TERM=vt100|tty does no good)

What do I need to do to get login and bash to work?

TIA,

Dwarf

------------                                          --------------

aka   Dale Scheetz                   Phone:   1 (904) 877-0257
      Flexible Software              Fax:     NONE 
      Black Creek Critters           e-mail:  [email-masked]

------------ If you don't see what you want, just ask --------------

---

From: Guy Maor <[email-masked]>
Date: Thu, 6 Jun 1996 22:20:05 -0500 (CDT)

> terminal (ok, ok, but I got it for free. In fact I have 6 of them) but I

Install ncurses-term, and use one of these terminal types.

$ toe | grep -i 'data general'
dg200           data general dasher 200
dg460-ansi      Data General Dasher 460 in ANSI-mode
dg6053          data general 6053
dg211           Data General d211
dg450           data general 6134

Guy

---

From: Eric Hoeltzel <[email-masked]>
Date: Thu, 6 Jun 1996 23:48:03 -0700 (PDT)

> What do I need to do to get login and bash to work?

Maybe you could nose around in /etc/termcap and find something
that has to do with Data General. vt100 probably isn't going to
help you.

Regards,
Eric

---

From: Dale Scheetz <[email-masked]>
Date: Fri, 7 Jun 1996 08:21:12 -0400 (EDT)

> dg460-ansi      Data General Dasher 460 in ANSI-mode
I installed ncurses-term-1.9.9e-1.deb but when I do the toe above I get:

infocmp: can't open terminfo file BUGS.

Any Ideas?

Dwarf

------------ If you don't see what you want, just ask --------------

---

From: Guy Maor <[email-masked]>
Date: Fri, 7 Jun 1996 07:57:19 -0500 (CDT)

> infocmp: can't open terminfo file BUGS.

toe is Table Of Entries.  It just lists all the available terminfo
entries with a description.

If you ran it with no options and it gave you this error, that means
you have a file called 'BUGS' somewhere in your /usr/lib/terminfo
tree.  toe couldn't parse it because it wasn't a terminfo file.

Go look for this file BUGS, and see what package is generating it.
It's not in ncurses-term-1.9.9e-1.

Regarding your terminal, match the model # with one of those terminals
and use that as your TERM setting.

Guy

---

From: Dale Scheetz <[email-masked]>
Date: Fri, 7 Jun 1996 09:21:25 -0400 (EDT)

> It's not in ncurses-term-1.9.9e-1.

Here's the 'ls -a /usr/lib/terminfo'

.
..
0
1
2
3
4
5
6
7
8
9
A
B
C
D
E
F
G
H
I
J
K
L
M
N
O
P
Q
R
S
T
U
V
W
X
Y
Z
a
b
c
d
e
f
g
h
i
j
k
l
m
n
o
p
q
r
s
t
terminfo
u
v
w
x
y
z

> and use that as your TERM setting.
I looked in /etc/termcap (is this the right place?) and found dg460-ansi.
When I added this to the line in inittab for getty and -HUP init the
results of the login are exactly the same.

Am I doing this right? It acts like the termtype is being totally ignored,
or at least not passed to login and bash.

Is there any way that I can check the termtype of this process from the
console? That is, can I find out what termtype the bash on ttyS1 is from a
root login at the console?

TIA,

Dwarf

------------ If you don't see what you want, just ask --------------

---

From: Guy Maor <[email-masked]>
Date: Fri, 7 Jun 1996 08:39:46 -0500 (CDT)

> Here's the 'ls -a /usr/lib/terminfo'

Why did you send me that?  The BUGS file is probably in one of those
subdirs.  Since I don't want an ls -R /usr/lib/terminfo in my mbox,
I'll reveal the magic incantation 'find /usr/lib/terminfo -name BUGS'.

> I looked in /etc/termcap (is this the right place?)

no.  ncurses uses terminfo.

> console?

cat /proc/xxx/environ | xargs -0n1
will you show you the environment of pid xxx.  grep for TERM.

Guy

---

From: Steve Preston <[email-masked]>
Date: Fri, 7 Jun 1996 12:23:30 -0400

>>>>> Dale Scheetz <[email-masked]> writes:

> On Fri, 7 Jun 1996, Steve Preston wrote:

>> One explanation that would fit this behavior is that your terminal
>> is configured to expect more stop bits than the linux box is
>> sending.

> This is a very nice idea, except that it ignores the fact that getty
> can print the login message to the terminal just fine. It is only
> login and bash that don't seem to talk right. I don't see how getty
> could send slow enough to not error and login not. They are both
> using the same driver, aren't they?

Yes, they use the same driver, but your problem starts when getty
exec's login.  So I suspect that login is changing the characteristics
of the tty.

I just looked at the termios manpage, and it is possible to set the
number of stop bits to 1 or 2 (see the CSTOPB constant).  It is also
possible to set the number of databits (see the CSIZE constant) to
anything from 5 to 8.  It could be that getty sets csize and cstopb to
liberal values, like 8 data bits and 2 stop bits, and login sets one
and/or the other to smaller values.

>From bash or whatever shell, you can try saying
  stty cs8 cstopb

-- 
Steve Preston ([email-masked])

---

From: Dale Scheetz <[email-masked]>
Date: Fri, 7 Jun 1996 12:02:31 -0400 (EDT)

On Fri, 7 Jun 1996, Steve Preston wrote:

> One explanation that would fit this behavior is that your terminal is
> configured to expect more stop bits than the linux box is sending.
> 
> When you are typing and the linux box is echoing, there are long
> pauses (relative to a single bit time) between each character.  With
> these pauses, it is irrelevant how many stop bits the linux box sends,
> since the stop bits blend in with the pause.  That is, the pause after
> a character consists of a bunch of extra stop bits.
> 
> However, when the linux box is sending characters as fast as it can,
> then the start bit of the next character follows immediately after
> however many stop bits were sent previously.
> 
> If the receiver is expecting 2 stop bits, and the linux box is only
> sending 1, then the receiver will detect framing errors or, if it
> ignores framing errors, it will simply get out of sync.  That is why
> you see only six characters instead of the 9 in the "Password:"
> prompt.
> 
This is a very nice idea, except that it ignores the fact that getty can
print the login message to the terminal just fine. It is only login and
bash that don't seem to talk right. I don't see how getty could send slow
enough to not error and login not. They are both using the same driver,
aren't they?

Thanks for the idea,

Dwarf

------------ If you don't see what you want, just ask --------------

---

From: Steve Preston <[email-masked]>
Date: Fri, 7 Jun 1996 10:29:06 -0400

I don't know if ttyS1 can be configured to send more stop bits.
Perhaps your terminal can be configured to expect fewer.

---

From: Dale Scheetz <[email-masked]>
Date: Fri, 7 Jun 1996 11:35:22 -0400 (EDT)

> > Here's the 'ls -a /usr/lib/terminfo'

Ooops, how dull of me :-)
> I'll reveal the magic incantation 'find /usr/lib/terminfo -name BUGS'.
This yields nothing. There is no BUGS file in and subs of
/usr/lib/terminfo.?

> no.  ncurses uses terminfo.
/usr/lib/termifo or /etc/terminfo? These are conciderably different.
/etc/terminfo only has a (ansi) d (dump) l (linux) s (sun) v (vtxxx) and x
(xterm...)

> will you show you the environment of pid xxx.  grep for TERM.
This works! It tells me that the bash running on ttyS1 is, in fact,
running with the termtype passed by getty. However, none of the termtypes
I have tried have made any difference at all! I have tried: ansi, dumb,
dg6134, and dg640-ansi with no effect at all.

I would suspect the terminal, except getty writes cleanly to the terminal.
It is only login and bash that misbehave.

Still banging my head,

Dwarf

------------ If you don't see what you want, just ask --------------

---

From: Dale Scheetz <[email-masked]>
Date: Fri, 7 Jun 1996 15:01:53 -0400 (EDT)

> >From bash or whatever shell, you can try saying

Ok! We are narrowing the field. 

The above command locks up the terminal big time, but...

stty cs7 cstopb

fixes it!

Now the question is: How do I get login to leave the stop bits alone?
I can put the above command into .bashrc, but this will not fix login and
I will still get the bunged password prompt.
Looks like it's time to talk with Guy :-)

Thanks for all the help,

Dwarf

------------ If you don't see what you want, just ask --------------

---

From: Guy Maor <[email-masked]>
Date: Fri, 7 Jun 1996 16:01:56 -0500 (CDT)

> This yields nothing. There is no BUGS file in and subs of

I'm only assuming there is because of your weird error.  I got the same
error when I manually created a file called BUGS.

> /etc/terminfo only has a (ansi) d (dump) l (linux) s (sun) v (vtxxx) and x

/usr/lib/terminfo is the full terminfo library, but may not be
available on boot.  /etc/terminfo presumably contains the console
entry.  If you boot off this terminal, be sure and copy the right
terminfo entry into here.

> It is only login and bash that misbehave.

You told me in other mail that the problem was fixed with 'stty cs7
cstopb'.  I think I know what the problem is, login doing a vhangup()
when it shouldn't, but I have to think if my solution is safe.  I'll
get back to you.

Guy

---

From: Craig Sanders <[email-masked]>
Date: Tue, 11 Jun 1996 09:54:59 +1000 (EST)

> Looks like it's time to talk with Guy :-)

Sounds like you've nearly got it working, but here's a tip for you:

Rather than change s/w settings on the unix box, change the setup on the
terminal(s) so that they are as 'standard' as possible.  This means, if
the terminal setup allows it, set them to 8 data bits, 1 stop bit, no
parity.  Also, unless the term's native mode provides features you need,
set the terminal to emulate vt-100 or similar.

This way, you (or whoever logs in on the terminal) can avoid having
to have special case stuff in ~/.bashrc, ~/.bash_profile to set the
environment properly according to where they've logged in from.

It also follows the KISS principle - Keep It Simple Stupid - which i've
found is a damn good principle to follow :-)

i went down the same 'terminals are cheap/free so use them' path when
i first started with linux a few years ago...in fact, multi-user &
cheap/free dumb terminals was one of the main reasons i originally
switched to linux.  

So if you're still having troubles email me and i'll do what i can to help
you out.  email me directly...i just accepted a new job and dont have as
much time to read the mailing lists as i used to. 

Another way of doing it:
------------------------

If you CAN'T for some reason set the terminal as above, then you'll have
to edit /etc/rc.boot/0setserial to do an 'stty cs7 cstopb' or whatever
else is needed on the terminal.  Setting the line characteristics of
a hardwired terminal should be done BEFORE getty or login run on the
terminal - i.e. during the bootup process.

Also, if you do this you might want to put something like the following
in /etc/profile, to force the right settings every time someone logs in
(just in case the previous logged in user mucked up the stty settings):

if [ "`tty`" = "/dev/ttyS1" ] ; then
  stty cs7 cstopb
  alias exit='stty cs7 cstopb ; exit'
  alias logout='stty cs7 cstopb ; logout'
fi

This runs the right stty command at login, and aliases 'exit' and 'logout'
to make sure they're set properly on logout.

Craig

---

From: eckes <[email-masked]>
Date: Mon, 10 Jun 1996 13:12:44 +0200 (MET DST)

> Now the question is: How do I get login to leave the stop bits alone?
/etc/gettydefs is used for this, but debian has no support for it.. hmm..
guess thats a login problem.

Greetings
Bernd
-- 
  (OO)      -- [email-masked] --
 ( .. )  ecki@lina.{inka.de,ka.sub.org}  http://home.pages.de/~eckes/
  o--o     *plush*  2048/A2C51749  eckes@irc  +4972573817  *plush*
(O____O)       If privacy is outlawed only Outlaws have privacy