[comp.unix.ultrix] File-completion on Ultrix V4 uses backspace with 8th bit set

ralph@uhheph.phys.hawaii.edu (Ralph Becker-Szendy) (05/25/91)

Little weird problem. Under Ultrix on a DS5000 using the csh, I "set filec"
to enable file completion. When I hit the escape key to complete a file name
(g**d*** LK201 keyboard doesn't have one, but many other terminals
fortunately do), the csh does the following:
- it echoes "^[",
- it outputs two backspaces and two spaces (to cover up the ^[),
- it outputs two more backspaces, to get back to where we left off,
- and it outputs the rest of the filename.

Unfortunately, it outputs the backspaces with the 8th bit set ! On a VT100 or
a DECterm under DECwindows that causes no problem; the old 7-bit terminals
just strip the highest bit off and execute a backspace. The DECterm
automagically knows that a backspace is a backspace even with the high bit
set. But VT2xx and compatible terminals will not execute the backspace with
the high bit set. That leads to screen output like
"cd ca^[  lculate/fi^[  ndpeaks" for what should have been 
"cd calculate/findpeaks". 

Is there a way to fix that ? I assume it must be my fault. For completeness,
I am including the output of "stty everything" and my personal termcap (which
is just a copy of the DEC supplied termcap, with the fa5220 for the Falco
terminal operating with 49 lines added):

============= stty everything log ===========
new tty, speed 0 baud , 0 rows, 0 columns
even odd -raw -nl echo -lcase -tandem -tabs -cbreak 
crtbs
 crterase -crtkill ctlecho -prterase -tostop 
-tilde -flusho -litout -pass8 -nohang -autoflow 
-pend
in -decctlq -noflsh 
erase  kill   werase rprnt  flush  lnext  susp   intr   quit   stop   eof
^?     ^U     ^W     ^R     ^O     ^V     ^Z/^Y  ^C     ^\     ^S/^Q  ^D     

============= my personal termcap , clipped to the terminals of interest =====
dr|vt100p|vt100p-nam|dec vt100p:\
	:am:\
	:al=\E[L:\
	:bl=^G:\
	:bs:\
	:cd=50\E[J:\
	:ce=3\E[K:\
	:cl=50\E[;H\E[2J:\
	:cm=10\E[%i%d;%dH:\
	:co#80:\
	:cr=^M:\
	:cs=\E[%i%d;%dr:\
	:dc=\E[P:\
	:dl=\E[M:\
	:do=^J:\
	:ei=\E[4l:\
	:ho=\E[H:\
	:im=\E[4h:\
	:is=\E[1;24r\E[24;1H:\
	:k1=\EOP:\
	:k2=\EOQ:\
	:k3=\EOR:\
	:k4=\EOS:\
	:kb=^H:\
	:kd=\EOB:\
	:ke=\E[?1l\E>:\
	:kl=\EOD:\
	:kr=\EOC:\
	:ks=\E[?1h\E=:\
	:ku=\EOA:\
	:le=^H:\
	:li#24:\
	:md=2\E[1m:\
	:mr=2\E[7m:\
	:mb=2\E[5m:\
	:me=2\E[m:\
	:mi:\
	:nd=\E[C:\
	:nl=^J:\
	:pt:\
	:rc=\E8:\
	:rf=/usr/lib/tabset/vt100:\
	:rs=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h:\
	:sc=\E7:\
	:se=\E[m:\
	:so=\E[7m:\
	:sr=\EM:\
	:ta=^I:\
	:ue=\E[m:\
	:up=\E[A:\
	:us=\E[4m:\
	:vt#3:\
	:xn:
da|vt200|vt200-nam|dec vt200:\
	:ae=4\E(B:\
	:as=2\E(<:\
	:tc=vt100p:
db|vt300|dec vt300:\
	:hs:\
	:es:\
	:ts=\E[1$}\E[;H\E[K:\
	:fs=\E[0$}:\
	:ds=\E[1$}\E[;H\E[K\E[0$}:\
	:tc=vt200:
Ra|fa5220|falco f5xxx 49 lines:\
	:li#49:\
	:is=\E1;49r\E[49;1H:\
	:tc=vt200:

Thanks for any enlightenment.

-- 
Ralph Becker-Szendy                          UHHEPG=24742::RALPH (HEPNet,SPAN)
University of Hawaii                              RALPH@UHHEPG.PHYS.HAWAII.EDU
High Energy Physics Group                                  RALPH@UHHEPG.BITNET
Watanabe Hall #203, 2505 Correa Road, Honolulu, HI 96822         (808)956-2931

mellon@nigiri.pa.dec.com (Ted Lemon) (05/28/91)

Nope, it's not your fault.  It's what we fondly refer to as a "bug".
You might try setting your VT220 or VT320 into ``seven bit'' mode -
perhaps it'll then strip the extra bit.  Chances are that unless
you're using the special Hawaiian character set, you're not using the
eight bit functionality anyway.  If you're using Xterm, the Ultrix 4.2
version of Xterm has a workaround installed - just add the following
line to your .Xdefaults file:

XTerm.decCShellFix:     true

This will only work with the DEC-supplied version of xterm, of course.
If you have your own version build from source, I can supply you with
a patch to enable this functionality.

			       _MelloN_

P.S. DEC doesn't support a Hawaiian character set, and as far as I
know, has no plans to support one in the future.   I was just kidding.
:')