sudweeks@megatest.UUCP (Bruce Sudweeks) (12/02/88)
I seem to have found a bug in vi. I'm running UCB version 3.7 on a sun 3/50.
The problem occurs when I use global search and destroy type commands.
Following the command execution, ALL of my buffers get wiped out. For
example: (yank something into a buffer first, then try to retrieve it after-
wards).
#### replace every occurance of pattern with pattern2 until end of file ####
:.,$g/pattern/s//pattern2/
#### replace first occurance of pattern with pattern2 in all files which
have PATTERN in them ####
:g/PATTERN/s/pattern/pattern2/
These are just a couple examples. I have tried a number of the global commands
with the same results. Has anyone else seen this bug?
-Bruce-
e-mail { sun, pyramid } sudweeks@megatest
ps. please don't send me work-a-rounds for the above two examples, In most cases
I have figured out ones myself. I would just like to know if there is a copy
of vi which doesn't exhibit this problem.malpass@vlsi.ll.mit.edu (Don Malpass) (12/03/88)
In article <1039@desert.megatest.UUCP> sudweeks@megatest.UUCP (Bruce Sudweeks) writes: >I seem to have found a bug in vi. > #### replace every occurance of pattern with pattern2 until end of file #### > > :.,$g/pattern/s//pattern2/ I'm home and not near any documentation, but I think that your use of 'g' here with ".,$" is improper. Global HERE means EVERY LINE, so the range probably gets ignored. You should simply do :.,$ s/pattern/pattern2/g In this case the TRAILING 'g' says to make the substitution more than once per line if necessary, but the specified range will be honored. I think your second illustration (which I've cleverly deleted from this file before talking about it, so this may be nonsense) is correct: it will check ALL lines - not a range - for PATTERN and if it finds it will make one substitution only in such lines. I'll not suggest you RTFM, because that is precisely what's wrong with vi: reading most of its documentation is about like having root canal done - rectally. Good luck. -- Don Malpass [malpass@LL-vlsi.arpa], [malpass@gandalf.ll.mit.edu] The Malpass Principle: Given a binary choice, the statistical probability of doing the right thing is 31.7% - on good days.
gast@lanai.cs.ucla.edu (David Gast) (12/07/88)
In article <1039@desert.megatest.UUCP> sudweeks@megatest.UUCP (Bruce Sudweeks) writes: >I seem to have found a bug in vi. I'm running UCB version 3.7 on a sun 3/50. > > #### replace every occurance of pattern with pattern2 until end of file #### > :.,$g/pattern/s//pattern2/ The following will work just as well as the above and they require less typing. The second form works much faster for the trivial case you want to do. :g/pattern/s//pattern2/ :%s/pattern/pattern2/ > #### replace first occurance of pattern with pattern2 in all files which > have PATTERN in them #### Eh? This command still only affects the current file, not all files which have PATTERN in them. It substitutes pattern2 for pattern on all lines which have PATTERN. > :g/PATTERN/s/pattern/pattern2/ The three patterns give you a surprising flexibility. You can change all the lines which have pattern on the line after PATTERN, for example. The global command allows any ex command to be issued. :g/pattern/d deletes every line with pattern. >A problem occurs when I use global search and destroy type commands. >Following the command execution, ALL of my buffers get wiped out. For >example: (yank something into a buffer first, then try to retrieve it after- >wards). On our suns, this problem seems to be temporary. It does not alwyas affect all of the buffers, but if it does, the next command (like an a, i, o, etc) that you do restores all of the buffers except that the unnamed and unnumbered buffer becomes "1 and presumably "N becomes "N+1 for N = 1 to 8. You can, of course, undo that last command. The unnamed buffer becomes associated with the global command. I would actually guess that this is considered a feature, not a bug. Suppose that you do %s/string/newstring/g instead of g/string/s//newstring/g then none of the named buffers are affected, the "N buffer becomes the "N+1 buffer, and the unnamed and unnumbered buffer contains the original lines before they were changed. They do not appear to be wiped out even immediately after the global change. >ps. please don't send me work-a-rounds for the above two examples, In most cases >I have figured out ones myself. I would just like to know if there is a copy >of vi which doesn't exhibit this problem. While you may have figured all of this out, other readers may be interested in knowing that they have not lost all of their buffers. David Gast gast@cs.ucla.edu {uunet,ucbvax,rutgers}!{ucla-cs,cs.ucla.edu}!gast