Xref: utzoo comp.bugs.sys5:1307 comp.unix.i386:7054 comp.unix.questions:23933 comp.unix.xenix:12486 Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!cbnewsl!rubin From: rubin@cbnewsl.att.com (Mike Rubin) Newsgroups: comp.bugs.sys5,comp.unix.i386,comp.unix.questions,comp.unix.xenix Subject: Re: Obscure Vi bug? Keywords: Yes, even in SVR4.0; I'll officially report it Message-ID: <1990Jul20.133540.18676@cbnewsl.att.com> Date: 20 Jul 90 13:35:40 GMT References: <798@intelhf.hf.intel.com> <846@mwtech.UUCP> Distribution: usa Organization: AT&T Bell Labs, Summit, NJ Lines: 32 In article <846@mwtech.UUCP> martin@mwtech.UUCP (Martin Weitzel) writes: >In article <798@intelhf.hf.intel.com> fredch@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 produced it in the following way: > >1) Take a file somewhat larger than your screen (50 lines are not > critical) >2) Make line "LINES+1" to be shown in the last line of your screen. > Use any command you like to do so, move the cursor to any place > you like, after you have positioned the screen. > (Note: LINES defaults to 25 for TERM=AT386; so line 26 schould > be last on the screen. You may verify this by ":set nu") >3) Type ^B (CTRL-B) ==> terminal beeps; screen *doesn't* change >4) Type ^L (Redraw screen) ==> Screen changes, topmost line is 1 now! >5) Type ^L once more ==> first line of screen changes and shows the > same as the line your cursor were in when you typed ^B in step 3) > >I hope somebody who can fix this bug will read this description. I have reproduced it in the current development load of AT&T SVR4.0/386 version 2.0. I'll file the trouble report; it may or may not get fixed in time for the next customer release. --Mike Rubin