[ On Monday, June 18, 2001 at 22:41:27 (-0400), Shannon Hendrix wrote: ]
> Subject: Re: DEC vt320 terminal problem
>
> On Mon, Jun 18, 2001 at 03:54:41PM -0400, Greg A. Woods wrote:
> 
> > I think there may be some inadvertent interaction with flow control and
> > the shell continually switching the tty setting.
> 
> I tried using rtscts hardware flow control, but it's not totally clear
> to me that the terminal supports it. It didn't give errors, but it seems
> that either shells turn this off, or the setting has no effect.

If it didn't give any errors, and didn't drop any characters, then it
works, no question!

> I think so. Going to 9600bps does reduced the problem a lot, except
> on the more complex shell prompts. I tried inserting some small 3-5ms
> delays in the termcap entry for newlines and carriage returns, but it
> seems to have no effect.
> 
> It might be you could leave the shell's stty code alone and just
> introduce delays, but I'm not yet convinced that would help.

The problem is that the user (or the terminal's autorepeat) cannot (or
will not) introduce the delays.  I.e. it's not possible to introduce
appropriate delays in the output -- they're needed in the *input*.

> This works fine. I have even wondered if this is a problem specific to
> NetBSD-sparc, or just the sparc hardware. Maybe toying with stty setup
> is OK on other hardware, or maybe it triggers an as yet unknown race
> condition or similar problem somewhere.

I doubt it's a sparc-only problem.  I'm too tired just now to actually
prove it with a console on an i386 machine, but I have almost no doubt
that the results will be the same....

> I don't see this myself, but it would also be caused by network/xterm
> interaction. I say that because I _have_ noticed that when using
> terminal servers before. Just a thought.

If you make your prompt long enough, and if your terminal is slow
enough, and if your baud rate is high enough, you'll definitely see the
"bunching" of prompts into one "line" because that's just the way things
work when then 

> Matches what I see. I don't quite understand why a shell would do
> something like that though. Also, if the tty driver needs to do flow
> control, I would think it would handle that the right way irregardless
> of what the user level program did.

It's not the shell that's actually causing the problem.  The shells
simply manifest the problem because they literally hammer on the tty
driver with a flip-flop of stty changes to disable and then re-enable
the command-line editing features between every prompt they print.
Whether or not the problem is avoidable or not, or whether it's simply
something that's bound to happen given the way the hardware works, is
not something I can declare either way for sure.

I'm fairly certain the problem does not occur with plain /bin/sh because
I don't think it is twiddling the stty settings with every prompt.

> I might peek at the shell sources; it's just a lot of code to digest.
> Hopefully one of them is reasonably modular, and the tty calls are
> well isolated.

I think you'd be better off (i.e more likely to find the problem) if you
were looking at the tty and line discipline sources (in conjunction with
the hardware manual for a UART).  :-)

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>