On Tue, Jun 19, 2001 at 04:54:10AM -0400, Greg A. Woods wrote:

> > 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 would have expected hardware flow control to allow full-speed output
to the terminal without xon/xoff. It doesn't. That's why I don't think
it really is working. For example, displaying a really large directory
with rtscts enabled still gives me garbage after the first couple of
pages. xon/xoff fixes this. Hardware flow control alone should be
sufficient.

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

I was watching traces of tcsh, and it sends the following string 
out for each prompt:

  8076 tcsh     GIO   fd 17 wrote 42 bytes
         "\^[[79C  \rescape:/home/shannon\^[[59C  \r204 % "

I see the the ioctl() call before each prompt and external execution.

Anyway, I think the problem is in that prompt string.  The first escape
code means cursor right 79 times.  Then two spaces and carriage return.
After printing the first prompt it does cursor right 59 times, two spaces
and carriage return.

The two spaces garantees a wrap and linefeed, the carriage return alone
should bring the cursor back to column 0. Obviously it's not working all
the time.

I personally think it would work better if it just issued a carriage
return and linefeed.  I know what you said about some applications
being paranoid about how that is handled, but I think this is worse.

I know in the past I found that some terminals were not fast enough to
handle wrapping on single character output and then doing _anything_
else for a few milliseconds.

> I doubt it's a sparc-only problem.

I will try to duplicate this on i386 sometime later this week. I
still have a 1.4.2 CD I believe. 

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

I'm now not entirely sure it's the hammering, mainly because I don't
see two ioctl() calls per prompt being all that hard on the driver or
the hardware. It could just be a matter of the iotcl() happening near
the same time as the linefeed, and the terminal handles that badly for
whatever reason.

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

It uses the same TIOCSETAW ioctl() calls, in much the same manner, as
tcsh does.

It doesn't use a cursor right command like tcsh does, but it does nearly
the same thing by outputting 80 spaces to force a wrap and linefeed.

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

I don't even think it's a uart problem.  When I can get this terminal 
hooked up to a different machine, one where it works, I will have
more data for comparisons.

-- 
"Whatever..." -- Kenny Gatdula
______________________________________________________________________
Charles Shannon Hendrix      s h a n n o n @ w i d o m a k e r . c o m