fredch@starlite.hf.intel.com (07/19/90)
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.
--
Fred Christiansen, Intel, JF1-67 503-696-4214 | fredch@starlite.hf.intel.com
5200 NE Elam Young Prkwy, Hillsboro, OR 97124 | uunet!intelhf!starlite!fredch
Investment Advice: No investments of your time will produce as enduring results
as time spent building character in your children.
----------
Fred Christiansen, Intel, JF1-67 503-696-4214 | fredch@starlite.hf.intel.com
5200 NE Elam Young Prkwy, Hillsboro, OR 97124 | uunet!intelhf!starlite!fredch
Investment Advice: No investments of your time will produce as enduring results
as time spent building character in your children.james@dlss2.UUCP (James Cummings) (07/19/90)
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 ^^^^^^^^^^^^ >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. >-- Fred, What are you talking about????? If you can go to 2 lines below the bottom of the file with a G command, you found a bug there! If two lines below the bottom of the file can be either line 25 or 26 of a 50 line file you found ANOTHER bug. Sit back, take a deep breath and try all this again. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |Disclaimer: | James Cummings | | You can't blame me! | UUCP: | | I'm ignorant! | ..swblat!{texbell!texnet.. | |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| swgate!dlss1..}!dlss2!james | |Send flames to: | NET: | | sowc@devnull.com | jc@smunews | | | | =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
martin@mwtech.UUCP (Martin Weitzel) (07/19/90)
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. *********************************************** ** ALL OTHERS BE WARNED: ** ** ** ** USING CTRL-B IN vi MAY RESULT IN CHANGING ** ** YOUR FILE UNDER CERTAIN CIRCUMSTANCES! ** *********************************************** Note: I've crossposted this to several other groups where the readers might be interested in this warning. Furthermore I'm not at all sure if this bug is specific to SysV. -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
rac@sherpa.UUCP (Roger Cornelius) (07/20/90)
From article <798@intelhf.hf.intel.com>, by fredch@starlite.hf.intel.com: > 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. This also occurs with the vi on SCO UNIX V3.2.0, which, when given the :version command reports SVR3.1. It doesn't appear to be file length specific. -- Roger A. Cornelius rac@sherpa.UUCP uunet!sherpa!rac
jon@hitachi.uucp (Jon Ryshpan) (07/20/90)
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. I see exactly the same thing on 386/ix Version 2.0.2. Vi is Version SVR3.1. Also vi also often returns a nonzero status, despite the fact that nothing seems to have gone wrong. Many Thanks: Jonathan Ryshpan <...!uunet!hitachi!jon> M/S 420 (415) 244-7369 Hitachi America Ltd. 2000 Sierra Pt. Pkwy. Brisbane CA 94005-1819
greim@sbsvax.cs.uni-sb.de (Michael Greim) (07/20/90)
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: = [... detailed description of how to reproduce bug ...] I tried it on several machines with several 24 and 25 line terminals. I could not reproduce the bug. As all these systems are BSD or -related, it seems that the bug is specific to the SYS V version of vi. -mg -- .-. .-. .-. Michael Greim ( X )( __) e-mail : greim@cs.uni-sb.de \ / \ / \ / or : ...!uunet!unido!sbsvax!greim ~ ~ ~
rubin@cbnewsl.att.com (Mike Rubin) (07/20/90)
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 <mike@attunix.att.com, address changing soon>
james@dlss2.UUCP (James Cummings) (07/20/90)
Yes, this appears to be a bug in vi. I get the same results, now that I understand the problem. If a set report=1 is done there is not even a notification that any line has been changed. Enviornment: System V r 3.2.1 AT&T 3B2/700 Output from "what" for vi: /usr/bin/vi: printf.c:2.2 6/5/79 /usr/bin/vi.sl 1.31 3.2 01/06/88 16362 AT&T-SF -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ |Disclaimer: | James Cummings | | You can't blame me! | UUCP: | | I'm ignorant! | ..swblat!{texbell!texnet.. | |+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+| swgate!dlss1..}!dlss2!james | |Send flames to: | NET: | | sowc@devnull.com | jc@smunews | | | | =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
peter@ficc.ferranti.com (Peter da Silva) (07/20/90)
Another bug in 'vi' relates to the use of uparrow to switch to another file. If it fails for any reason, it will do weird things. It might be as benign as throwing you into line mode (repeat by: starting in a modified file, ":f non-existent-file" then "^^") or erasing the current line. That one I can't create on demand, but it's happened several times. -- Peter da Silva. `-_-' +1 713 274 5180. 'U` <peter@ficc.ferranti.com>
kdq@demott.COM (Kevin D. Quitt) (07/20/90)
This bug does not occur on the Motorola Delta Series SYSV machines.
(Other ones do, though 8-{)}
--
_
Kevin D. Quitt demott!kdq kdq@demott.com
DeMott Electronics Co. 14707 Keswick St. Van Nuys, CA 91405-1266
VOICE (818) 988-4975 FAX (818) 997-1190 MODEM (818) 997-4496 PEP last
96.37% of all statistics are made up.mday@iconsys (Matt Day) (07/21/90)
In article <92@dlss2.UUCP> james@dlss2.UUCP (James Cummings) writes: > What are you talking about????? If you can go to 2 lines below > the bottom of the file with a G command, you found a bug there! > If two lines below the bottom of the file can be either line 25 > or 26 of a 50 line file you found ANOTHER bug. I think he meant position the cursor on the second line below the bottom line displayed on the screen; therefore, on a 24 line screen, "vi" uses a 23 line window for displaying the file, and the 25th line is the second line below the 23rd. This bug both exists in SVR3.2 and SVR4. It's quite a disaster, isn't it? -- - Matthew T. Day, Sanyo/ICON, mday@iconsys.icon.com || uunet!iconsys!mday
lfd@cbnewsm.att.com (leland.f.derbenwick) (07/21/90)
In article <462@hitachi.uucp>, jon@hitachi.uucp (Jon Ryshpan) writes: > [ ... ] Vi is Version > SVR3.1. Also vi also often returns a nonzero status, despite the fact > that nothing seems to have gone wrong. Some versions of vi [I don't know exactly which ones, but they include the one on cbnewsm :-( ] apparently count failed searches and 'f', 't', etc., commands that you issued. For example, if you edit a file, do three searches that return "Pattern not found", then exit, vi will have a return code of 3. For my own sanity, I have a shell called "vi" in my bin that runs the /usr/bin/vi and then does an exit 0. That way I don't get "couldn't run editor" messages when I try to post something like this. -- Speaking strictly for myself, -- Lee Derbenwick, AT&T Bell Laboratories, Warren, NJ -- lfd@cbnewsm.ATT.COM or <wherever>!att!cbnewsm!lfd
flee@guardian.cs.psu.edu (Felix Lee) (07/21/90)
I've seen a similar problem running vi under SunOS 4.1. (SunOS 4.1 is shipped with some System-V version of vi). The display of lines gets scrambled, the file isn't actually changed, ctrl-L redraws the screen to exactly the same confused state, but strangely enough, ctrl-G will fix the display. -- Felix Lee flee@cs.psu.edu
guy@auspex.auspex.com (Guy Harris) (07/22/90)
>I've seen a similar problem running vi under SunOS 4.1. (SunOS 4.1 is >shipped with some System-V version of vi). System V Release 3.1, with assorted fixes to some bugs found at Sun (most of which, as I remember, were also in the 4.[23]BSD one), tag stack stuff added, and "modelines" renamed back to "modeline", 4.xBSD-style.
david@twg.com (David S. Herron) (07/23/90)
Well, gee, as long as we're gonna pour out some vi bugs.. On (at least) SysVr3.1 and r3.2 on the 3b2 line if you use the '!' command to filter some text, then a zombie is left around. You do that enough times and you fill up the process table with zombies and somebody comes to your cubicle and asks what's going wrong with the system. At least that's what happened to me the time I was playing with some tables of information for which I had an awk(1) script which recalculated the tables... Short-Version: The filter command in vi leaves a zombie hanging. Fix: Do a wait(2), silly! -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/24/90)
In article <92@dlss2.UUCP> james@dlss2.UUCP (James Cummings) writes: > What are you talking about????? If you can go to 2 lines below > the bottom of the file with a G command, you found a bug there! Obviously by "bottom line" he meant "bottom of the display". This was evident from the example he gave.
kucharsk@number6.Solbourne.COM (William Kucharski) (07/24/90)
In article <7645@gollum.twg.com> david@twg.com (David S. Herron) writes: >Short-Version: The filter command in vi leaves a zombie hanging. > >Fix: Do a wait(2), silly! Come on, this is System V -- a sigset(SIGCLD, SIG_IGN) would do nicely, as it's obviously not concerned about exit values if it's leaving zombies now... -- =============================================================================== | Internet: kucharsk@Solbourne.COM | William Kucharski | | uucp: ...!{boulder,sun,uunet}!stan!kucharsk | Solbourne Computer, Inc. | = The opinions above are mine alone and NOT those of Solbourne Computer, Inc. =
rick@tetrauk.UUCP (Rick Jones) (07/25/90)
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 can confirm this happens with SCO Unix, too (ODT version, at least). On this subject, this version has another annoying bug, involving the use of p or P in macros. E.g. I use a key mapping to swap adjacent characters, which is the sequence xph (the h keeps the cursor in the same position). As a macro, the h gets inserted into the text! This happens in any macro using p or P followed by other characters, all the subsequent characters get inserted, not obeyed as commands. Lots of macros won't work because of this, including the wonderful word-completion macro recently posted in comp.editors. Is this unique to the SCO version of vi? And will someone at SCO please fix it. -- Rick Jones You gotta stand for something Tetra Ltd. Maidenhead, Berks Or you'll fall for anything rick@tetrauk.uucp (...!ukc!tetrauk.uucp!rick) - John Cougar Mellencamp
martin@mwtech.UUCP (Martin Weitzel) (07/26/90)
In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: > >On this subject, this version has another annoying bug, involving the use of p >or P in macros. E.g. I use a key mapping to swap adjacent characters, which is >the sequence xph (the h keeps the cursor in the same position). As a macro, >the h gets inserted into the text! This happens in any macro using p or P >followed by other characters, all the subsequent characters get inserted, not >obeyed as commands. Lots of macros won't work because of this, including the >wonderful word-completion macro recently posted in comp.editors. > >Is this unique to the SCO version of vi? And will someone at SCO please fix >it. Same on ISC 386/ix 2.0.2 as I just tried. Strange enough that p and P work if they are the last command character of a mapped sequence. For any particular problem one may try to change the sequence so that the p or P appears last, like lxhhp which gives you what you expect from xph, but in general it's annoying. One more of these things (which I don't consider a real bug, as the topics this thread started with, but rather a "anomality"). The commands d, c, y, <, >, and ! require a following move. Has anybody allready noticed that this seems all fine but there's an inconsitency with a w-move vs. the e-move in the context of the c-command? Though e and w move to different places and do something different in case of the de- and ye-command, they behave the same when combined with the c-command. Shouldn't cw include the blanks after the word and only ce behave the way most of us know from cw. (Yes, it would be inconvienient to change habits, but it's not "logical" how it is now.) P.S. Wouldn't it be a nice idea to archive these "anomalities" somewhere. (Volunteers? Oh what a silence around - I could hear a penny fall ... :-)) -- Martin Weitzel, email: martin@mwtech.UUCP, voice: 49-(0)6151-6 56 83
rob@dutncp8.tudelft.nl (Rob Kurver) (07/27/90)
In <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >On this subject, this version has another annoying bug, involving the use of p >or P in macros. E.g. I use a key mapping to swap adjacent characters, which is >the sequence xph (the h keeps the cursor in the same position). As a macro, >the h gets inserted into the text! This happens in any macro using p or P >followed by other characters, all the subsequent characters get inserted, not >obeyed as commands. Lots of macros won't work because of this, including the >wonderful word-completion macro recently posted in comp.editors. >Is this unique to the SCO version of vi? And will someone at SCO please fix >it. I've experienced the same problem with the ESIX version of vi. When used in a macro, p and P don't work correctly. -- Rob Kurver rob@dutncp8.tudelft.nl Computational Physics Group rob@pact.nl Faculty of Applied Physics, Delft University of Technology Learning French is trivial: the word for horse is cheval, and everything else follows in the same way. -- Alan J. Perlis
rpw3@rigden.wpd.sgi.com (Rob Warnock) (07/28/90)
In article <295@sherpa.UUCP> rac@sherpa.UUCP (Roger Cornelius) writes: +--------------- | From article <798@intelhf.hf.intel.com>, by fredch@starlite.hf.intel.com: | > 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. | | This also occurs with the vi on SCO UNIX V3.2.0, which, when given the | :version command reports SVR3.1. It doesn't appear to be file length | specific. +--------------- This does *not* fail on an SGI 4D/25 (Irix 3.3). I tried "G"ing to +0, +1, +2, +3 lines below the bottom one on the screen; "^B" always worked properly from there, no beeps, no altering of text. The ":version" command reports "Version SVR3.1". I don't know if the fix is local to SGI, or possibly the bug is only in '386 versions of System-V. -ROb ----- Rob Warnock, MS-9U/510 rpw3@sgi.com rpw3@pei.com Silicon Graphics, Inc. (415)335-1673 Protocol Engines, Inc. 2011 N. Shoreline Blvd. Mountain View, CA 94039-7311
petebob@sequent.UUCP (Pete_Bob Apple) (07/30/90)
In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >On this subject, this version has another annoying bug, involving the use of p >or P in macros. E.g. I use a key mapping to swap adjacent characters, which is >the sequence xph (the h keeps the cursor in the same position). As a macro, >the h gets inserted into the text! This happens in any macro using p or P >followed by other characters, all the subsequent characters get inserted, not >obeyed as commands. Lots of macros won't work because of this, including the >wonderful word-completion macro recently posted in comp.editors. > >Is this unique to the SCO version of vi? And will someone at SCO please fix >it. From some investigation, this bug seems to be related to how the sys5 version of vi treats the p. It tosses the p, and inserts an 'a' into the command queue, to append the last buffer. Unfortunately, it seems the append that happens doesn't end after the buffer, and ends up appending the rest of your macro as well. Need an escape sequence in there to work around it. On our version of vi (at least), if you use the sequence xp<ESC>h, it works correctly. A hack, in the very least. Pete_Bob -- 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
lester@ingr.com (Lester Bartel) (07/30/90)
While we are on the subject of vi macro bugs, I have one to add. I cannot seem to make the | (pipe) work in a macro. What I want is a macro that will move my cursor to the 70th column (70|) so that I can split long lines onto shorter similar length lines easily. - Lester -- --- Lester Bartel b23b!naomi!lester@ingr.com Intergraph Corp. uunet!ingr!b23b!naomi!lester
petebob@sequent.UUCP (Pete_Bob Apple) (07/31/90)
In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: > >On this subject, this version has another annoying bug, involving the use of p >or P in macros. E.g. I use a key mapping to swap adjacent characters, which is >the sequence xph (the h keeps the cursor in the same position). As a macro, >the h gets inserted into the text! This happens in any macro using p or P >followed by other characters, all the subsequent characters get inserted, not >obeyed as commands. Lots of macros won't work because of this, including the >wonderful word-completion macro recently posted in comp.editors. > >Is this unique to the SCO version of vi? And will someone at SCO please fix >it. > I've got a fix for those of you out there that might have source to modify. The fix is in the file ex_vget.c, in the getbr() function. Basically, the order in which the various strings are searched for input needs to be reordered. If you take a look at the file, you'll notice it looks for input from a few different buffers before going out to read something new. The bug occurs because when the p command goes to read the characters to "put", it ends up reading in the rest of the macro before the input characters themselves. This is the current order of the buffers searched: if (Peekkey) { ... } /* Peek ahead buffer */ if (vmacp) { ... } /* Macro string buffer */ if (Peek2key) { ... } /* 2nd Peek ahead buffer*/ if (vglobp) { ... } /* New text to insert */ The fix is to change the order like so: if (Peekkey) { ... } /* Peek ahead buffer */ if (Peek2key) { ... } /* 2nd Peek ahead buffer*/ if (vglobp) { ... } /* New text to insert */ if (vmacp) { ... } /* Macro string buffer */ This bug exists in V.3.2, and V.4 as well. -- 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
josef@nixpbe.UUCP (Moellers) (08/01/90)
In <11626@ingr.com> lester@ingr.com (Lester Bartel) writes: >While we are on the subject of vi macro bugs, I have one to add. >I cannot seem to make the | (pipe) work in a macro. What I want is >a macro that will move my cursor to the 70th column (70|) so that I can >split long lines onto shorter similar length lines easily. The problem is, that the bar (|) is a meta character "in the command line" (How do I express what I want to say?). You can write "map a b | map c d" Unfortunately, there is no way of escaping the bar, like escaping the brackets ([]) by prefixing a backslash. I have given up trying to position into the 72nd column to do a line split. I write "map 0 072lBhs^M^[". Unformtunately this completely ignores tabs, but that's life. -- | Josef Moellers | c/o Nixdorf Computer AG | | USA: mollers.pad@nixbur.uucp | Abt. PXD-S14 | | !USA: mollers.pad@nixpbe.uucp | Heinz-Nixdorf-Ring | | Phone: (+49) 5251 104662 | D-4790 Paderborn |
lee@sq.sq.com (Liam R. E. Quin) (08/03/90)
josef@nixpbe.UUCP (Moellers) writes: >lester@ingr.com (Lester Bartel) writes: >>I cannot seem to make the | (pipe) work in a macro. >The problem is, that the bar (|) is a meta character "in the command >line" [...] You can write "map a b | map c d" >Unfortunately, there is no way of escaping the bar, like escaping the >brackets ([]) by prefixing a backslash. Actually, from vi, :map g 70^V^V| works fine. (type control-V, not ^V) It is tricky deciding when to use \ and when to use ^V, and how many of each to use, even if you understand the rules. Lee -- Liam R. E. Quin, lee@sq.com, {utai,utzoo}!sq!lee, SoftQuad Inc., Toronto ``He left her a copy of his calculations [...] Since she was a cystologist, she might have analysed the equations, but at the moment she was occupied with knitting a bootee.'' [John Boyd, Pollinators of Eden, 217]
jstuart@kentvax.kent.edu (Jeff Stuart) (08/03/90)
We have a problem here also with vi that when you edit a file and that file contains an ei: possibly followed by some text and then another : vi gives an error message. This happened on two machines, 1) Plexus P/75 running System V.2, and 2) Zilog Z80 running System V.2. The error message that we get on the zilog is bad register command and on the plexus it is something totally different. Has anyone seen this? -- Jeff Stuart Internet: telxon!teleng!kentba!jstuart@uunet.uu.net Kent State University UUCP: ...!uunet!telxon!teleng!kentba!jstuart Kent, Ohio 44242 (216) 672-3282 The opinions expressed here are my own only and not those of Computer Resources.
6sigma2@polari.UUCP (Brian Matthews) (08/03/90)
In article <1990Aug2.211449.24360@math-cs.kent.edu> jstuart@kentvax.kent.edu (Jeff Stuart) writes: |We have a problem here also with vi that when you edit a file and that |file contains an ei: possibly followed by some text and then another : |vi gives an error message. This happened on two machines, 1) Plexus |P/75 running System V.2, and 2) Zilog Z80 running System V.2. The error |message that we get on the zilog is bad register command and on the |plexus it is something totally different. Has anyone seen this? It will probably also happen with ex: or vi: or vx: This is a feature, of questionable utility, but a feature nonetheless. -- Brian L. Matthews blm@6sceng.UUCP
djz@cbnews.att.com (Danny Zerkel) (08/04/90)
In article <1990Aug2.211449.24360@math-cs.kent.edu> jstuart@kentvax.kent.edu (Jeff Stuart) writes: >We have a problem here also with vi that when you edit a file and that >file contains an ei: possibly followed by some text and then another : >vi gives an error message. This happened on two machines, 1) Plexus >P/75 running System V.2, and 2) Zilog Z80 running System V.2. The error >message that we get on the zilog is bad register command and on the >plexus it is something totally different. Has anyone seen this? > This problem shows up in SVR2. The code in ex (and vi) looks for 'e' or 'v' followed by 'x' or 'i' followed by ':' near the beginning or end of the file. It takes the rest of the line as a command line. We had a user 'pei' in the passwd file near the end. So everytime we vi'ed the passwd file, we'd get a stupid message. Danny J. Zerkel AT&T Bell Labs Columbus, OH (No, really! I can't believe it either!!)
mmengel@cuuxb.ATT.COM (~XT6561110~Marc Mengel~C25~M27~6184~) (08/04/90)
In article <rob.649040634@dutncp8> rob@dutncp8.tudelft.nl (Rob Kurver) writes: >In <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >> This happens in any macro using p or P >>followed by other characters, all the subsequent characters get inserted, not >>obeyed as commands. >I've experienced the same problem with the ESIX version of vi. When used >in a macro, p and P don't work correctly. Having hacked on vi in the past, I would suspect this is yet another buffer management bug; i.e. the buffer containing the macro is being labeled as the "current" buffer for the p command. You can *probably* work around this by using a named buffer, as in "ayyj"ap instead of yyjp in your favorite macros, as the vi buffer code is notoriously tough to make sense of... -- Marc Mengel mmengel@cuuxb.att.com attmail!mmengel ...!{lll-crg|att}!cuuxb!mmengel
dcm@moria.UUCP (David C. Miller) (08/05/90)
In <11626@ingr.com> lester@ingr.com (Lester Bartel) writes: |While we are on the subject of vi macro bugs, I have one to add. |I cannot seem to make the | (pipe) work in a macro. What I want is |a macro that will move my cursor to the 70th column (70|) so that I can |split long lines onto shorter similar length lines easily. In article <josef.649521753@peun11> josef@nixpbe.UUCP (Moellers) writes: |The problem is, that the bar (|) is a meta character "in the command |line" (How do I express what I want to say?). |You can write "map a b | map c d" |Unfortunately, there is no way of escaping the bar, like escaping the |brackets ([]) by prefixing a backslash. There is a way to do this, but it is not at all intuitive. What you want to write is "map a 70^V|". The ^V is actually an escaped ^V, so you need to type 2 ^V's before the '|'. David -- David C. Miller ka2qhd!moria!dcm@tsdiag.ocpt.ccur.com / uunet!moria!dcm
petebob@sequent.UUCP (Pete_Bob Apple) (08/06/90)
In article <618@tetrauk.UUCP> rick@tetrauk.UUCP (Rick Jones) writes: >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 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
honey@doom.ifs.umich.edu (Peter Honeyman) (08/18/90)
danny, YOU'RE NOT GONNA BELIEVE THIS but the MAJOR BUG FEATURE originated in YOUR TOWN! peter