On Sun, Jun 17, 2001 at 08:48:03PM -0400, Greg A. Woods wrote:

> Note of course that autowrap is necessary in almost all cases when
> you're _not_ using a curses-base application (and when using
[snip]

I turned autowrap off and switched to vt320-nam, just to see.  No
change.

> The ideal way to see what munging the shell does to tty settings is to
> login on a separate terminal simultaneously and on the second terminal
> compare the output from "stty -g < /dev/other_tty" (you can use "stty -a"
[snip]

I did that a few days ago, and noted the differences. I logged into
Linux with the terminal and also ran diffs against the stty settings
there. 

Interestingly, I just ran ksh and tried running less (pager), ksh,
and ksh with emacs editing.

There was no difference in the output when I ran "set -o emacs".

Also, I have noticed that even if I turn off the multi-line prompt,
I still get a character (a <= digraph in ksh and bash) overprinting
the first column. [ read on for what this is in detail ]

Also, if I set my prompt in tcsh or bash to be " % " then I get no
linefeeds, except rarely.

The character overwriting the first column varies, and occasionally I do
get a linefeed.

This has probably been happening before, the but more complex prompt was
obscuring most of it.

So just now I set the terminal to display rather than interpret controls,
and it prints this:

 % <cr><cr>u

...when I hit return after the ' % ' prompt.  The u is actually an
accented u' digraph. 

I should have thought of enabling this terminal feature before.

> > No, they don't.  I meant to note this earlier.
> 
> Ah ha!  This is intersting, though perhaps not yet enough information to
> point a finger at any one problem....

Maybe the above information will help.

It's almost like, when a shell is running, the terminal is getting high
ascii characters. This could be the shell munging stty settings and/or
sending escape codes. Though with the latter, I would have expected more
than a single character. Maybe the u' digraph is the result of an escape
sequence.

> > I actually
> > use this terminal, it's just just a console.
> 
> Does "just just" == "not just"?  (a new form of negative logic?  :-)

If you deprive yourself of enough sleep, there isn't anything negative
about it... :)

> The newlines alone may be the problem.
> 
> I suspect you're using tcsh (I don't remember if you mentioned this

Yes.

> /bin/ksh does appear to handle multi-line prompts OK (if you only use

ksh seems to have as much trouble as the rest.  If I hold down ^J and
let it autorepeat, I'll see the occasional >= digraph I mentioned
earlier.

Doing the same thing in any other program works fine.

The vt320 terminal uses an 8051 microprocessor as far as I know, and I
do have to use handshaking or it will lose data on fast outputs. It's
not the fastest terminal in the world, even though it's clocked at
16MHz.

But since this is still shell only, I was wondering if something is
happening, only in a shell prompt, that is causing a timing issue? Not
trying to confuse things, but it's a thought.

I have the same trouble at 9600bps BTW, so I don't think it's a simple case of
buffer overruns or some such.

Again using display instead of interpret controls, I get a stream of
<cr><cr><lf> characters from ksh with a simple $ prompt, with the
occasional <cr><cr>u' instead.

The u' digraph is coming in place of the linefeed, which sounds like
timing to me.  The simple prompt just causes this to happen much
less often, or at least that's what it looks like.

-- 
"Star Wars Moral Number 17: Teddy bears are dangerous in herds."