[ On Sunday, June 17, 2001 at 18:59:55 (-0400), Shannon wrote: ]
> Subject: Re: DEC vt320 terminal problem
>
> You are probably right. However, I have never had that set with this
> terminal before. Makes me at least curious about it.

Many curses-based applications are very pessimistic and don't seem to
make use of features that need autowrap (or reverse autowrap).  IIRC
traditional Unix 'vi' is one such (they stop printing at the last or
second last column and do the wrap themselves regardless of whether the
terminal can do it).  One "application" though that seems to require
both to work is /bin/sh, at least with 'emacs' command-line editing.

Note of course that autowrap is necessary in almost all cases when
you're _not_ using a curses-base application (and when using
curses-based apps you don't need/want it enabled if the termcap you are
using doesn't specify 'am' (and on many types of terminals, eg. vt100
there's a "vt100-am" terminal type that's supposed to be used when
autowrap is enabled, and a "vt100-nam" that's supposed to be used when
autowrap is disabled -- see below about aliases).

> I know the shell is doing that, but I thought bugs like this would
> exist in all platforms, not just NetBSD.  It certainly doesn't
> matter with Linux or DEC UNIX.

That depends on a lot of factors, including how well your particular
shell was ported to NetBSD.

The difference may simply be that in NetBSD the "vtXX0" terminal types
are an aliases for "vtXX0-am".  Other systems may alias "vt100" to the
"-nam" variant.  (I just checked SunOS-5.6 and it seems to have "vt100"
defined in much the same way as NetBSD.  There's no explicit vt320 type
there, but vt220 also has the 'am' capability.)

The comments for "DEC VT100 and compatibles" in /usr/share/misc/termcap
(which continue on after the "vt52" entry and again before other related
entries) are very enlightening and though dated from the point of view
of a VT320 user, useful none the less.

> It seemed to happen running /bin/sh too, but I might be mistaken: I
> didn't save stty settings from all shares when I was testing.  

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"
too, but '-g' output may be easier to compare if all you're looking for
are differences), first while the other tty's shell is sitting waiting
for input at a prompt, and then again while running a non-curses
application that's waiting for input (eg. "cat").  In this example I'm
running /bin/sh on /dev/ttyp2 with "set -o emacs" in the first run, and
"cat" in the second:

	# login (to /bin/sh) on ttyp2 and 'set -o emacs'....

$ stty -g < /dev/ttyp2
gfmt1:cflag=4b00:iflag=340:lflag=c3:oflag=3:discard=f:dsusp=ff:eof=ff:eol=ff:eol2=ff:erase=8:intr=7f:kill=15:lnext=ff:min=1:quit=1c:reprint=ff:start=11:status=ff:stop=13:susp=1a:time=0:werase=ff:ispeed=38400:ospeed=38400

	# go type "cat<CR>" on the other terminal....

$ stty -g < /dev/ttyp2 
gfmt1:cflag=4b00:iflag=300:lflag=5cf:oflag=3:discard=f:dsusp=19:eof=4:eol=ff:eol2=0:erase=8:intr=7f:kill=15:lnext=16:min=1:quit=1c:reprint=12:start=11:status=14:stop=13:susp=1a:time=0:werase=17:ispeed=38400:ospeed=38400

Note the differences in 'iflag', 'lflag', 'eof', 'eol2', 'dsusp',
'lnext', 'reprint', 'status', and 'werase'.  In the first case the shell
is doing all the editing itself, and in the second the tty driver (er,
line discipline) is all that's in control.

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

>  I don't find doing 
> without command line editing a viable alternative.

Oh, I wouldn't seriously suggest that -- it's just a necessary step in
this day and age of "smart" interactive shells.

> I actually
> use this terminal, it's just just a console.

Does "just just" == "not just"?  (a new form of negative logic?  :-)

> I hear you.  Still, I've been using this terminal with shell prompts
> like that for years.  I'd still like to figure this out, though I
> might just make editing work and forget the rest.
> 
> I don't put escape codes in the prompt.  There's nothing in there but
> newlines so the edit line is seperated from the information I want.

The newlines alone may be the problem.

I suspect you're using tcsh (I don't remember if you mentioned this
before or not, but if so I've forgotten already and my sincere apologies
if I've made the wrong assumption! ;-).

Note that /bin/sh won't properly handle multi-line prompts in all
cirumstances, at least not if you're using 'set -o emacs' (even though
it works OK if the prompt just wraps around!).  On the other hand
/bin/ksh does appear to handle multi-line prompts OK (if you only use
newlines to form them, that is; and so long as the input line doesn't
exceed the value of "stty columns").

Perhaps you could try /bin/ksh, and with the editing mode set to your
preferred variant.  Maybe its capabilities will be sufficient for your
needs, and it's bugs fewer given that it is a natively supported shell.

(I have neither csh nor tcsh on my systems and I refuse on principle
alone to even allow them to exist on my systems!  ;-)  ((I won't even
speak about bash... other than to say that its name describes what I
like to do to it.))

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