ron@trsvax (09/25/85)
Subject: bug in 3.6 vi (probably 3.7 also)
Description:
Vi has a bug in it when the ^^ (control ^) command is used if the
current file has been modified and there was no previous file edited
and vi set for autowrite.
On most terminals, the ^^ key is a deliberate action of the control
key and the ^ key. On others, this key may be labeled something
like 'f6' which might get hit accidently.
When, under the above circumstances, this key is hit, the current file
will be written out, the error message of "No filename substitute for #"
will be displayed, then the last line of the file will REPLACE the current
line the cursor is on. If at this point the ^^ key is accidently hit
again, the file, now with a bogus line, will be written out again.
Repeat-By:
% vi dont-care
:set aw (set autowrite)
(position the cursor to any line in the file)
dd (delete a line)
P (put it back)
^^
Fix:
Unknown. (but PLEASE don't tell me the answer is NOT to use
autowrite. That's like saying "if one of your headlights doesn't
work properly, don't use them")
{microsoft,ctvax}!trsvax!ron
Ron Lighthansen@pegasus.UUCP (Tony L. Hansen) (10/10/85)
< Subject: bug in 3.6 vi (probably 3.7 also) < < Description: < Vi has a bug in it when the ^^ (control ^) command is used if the < current file has been modified and there was no previous file edited < and vi set for autowrite. < ... < When, under the above circumstances, this key is hit, the current file < will be written out, the error message of "No filename substitute for #" < will be displayed, then the last line of the file will REPLACE the < current line the cursor is on. If at this point the ^^ key is < accidently hit again, the file, now with a bogus line, will be written < out again. I just checked my beta-version of 3.10 Vi (the version going into UNIX System Vr3) and the bug still exists. Maybe it'll get fixed for Vr4. Tony Hansen ihnp4!pegasus!hansen
chris@umcp-cs.UUCP (Chris Torek) (10/11/85)
I posted this once before but I think it did not make it out of the local machine. Apologies if you have seen this already ... This is not the correct way to fix it, but a forbid(altfile[0] == 0); under `case CTRL(^)' in ex_vmain.c would get around the problem. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251) UUCP: seismo!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@mimsy.umd.edu
dce@hammer.UUCP (David Elliott) (10/15/85)
This bug seems to be just an instance of a problem in the error printing code. Here are two known ways of making this kind of problem happen: 1. vi nonexistentfile ahi there david ews^[--wcw^[u^^ (^[ is escape, ^^ is control-^) The first line becomes the same as the last line. 2. vi nonexistentfile Alternately hit the interrupt and escape keys ten or fifteen times. Then, type ^L to redraw the screen. The first line of the file is now the word "Interrupt". David Elliott