Obscure Vi bug?

Pete_Bob Apple petebob at sequent.UUCP
Mon Aug 6 09:00:09 AEST 1990


In article <618 at tetrauk.UUCP> rick at tetrauk.UUCP (Rick Jones) writes:
>In article <846 at mwtech.UUCP> martin at mwtech.UUCP (Martin Weitzel) writes:
>>In article <798 at intelhf.hf.intel.com> fredch at starlite.hf.intel.com () writes:
>>>Has anyone else experienced this?  I have AT&T/Intel Unix V/386 on my box:
>>>
>>>Take a 50 line file (not sure if 50-line specific, but that's where I found it).
>>>Go to 2 lines below the bottom line using the G command.  For example, under
>>>TERM=xterm, go to line 25; under TERM=AT386 or TERM=vtpc, go to line 26.
>>>Then type ^B.  It will beep.  Then, type j.  Suddenly the current line will
>>>be copied onto line 1, and your file just got modified.
>>
>>Just tried this with ISC 386/ix 2.0.2 and SCO XENIX V. Same bug here.
>
>I can confirm this happens with SCO Unix, too (ODT version, at least).
>

I've a fix for this bug too, if you have vi source to recompile.
In V3.2 and V.4, the source for vi, the file ex_vmain.c:

----------------------------------------------
Change this:
                /*
                 * ^B           Window backwards, with 2 lines of continuity.
                 *              Inverse of ^F.
                 */
                case CTRL('b'):
                        vsave();
                        if (one + vcline != dot && vcnt > 2) {
>                                addr = dot - vcline - 2 - (cnt-1)*basWLINES;
                                forbid (addr <= zero);
                                dot = addr;
                                vcnt = vcline = 0;
                        }
                        vzop(0, 0, '^');
                        continue;

----------------------------------------------
To:
                /*
                 * ^B           Window backwards, with 2 lines of continuity.
                 *              Inverse of ^F.
                 */
                case CTRL('b'):
                        vsave();
                        if (one + vcline != dot && vcnt > 2) {
>                                addr = dot - vcline + 2 - (cnt-1)*basWLINES;
                                forbid (addr <= zero);
                                dot = addr;
                                vcnt = vcline = 0;
                        }
                        vzop(0, 0, '^');
                        continue;
----------------------------------------------

This fix makes CTRL-b operate correctly, and the bug goes away.  I compared
with the BSD world, and this fix was already in there.  

-- 
Pete_Bob Apple					Sequent Computer Systems
sequent!petebob					15450 S.W. Koll Parkway
Bob is not just a name..			Beaverton, Oregon 97006
It's a way of life.. 				(503) 626-5700



More information about the Comp.unix.i386 mailing list