Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!ucla-cs!gast
From: gast@lanai.cs.ucla.edu (David Gast)
Newsgroups: comp.editors
Subject: Re: global bug in vi
Message-ID: <18611@shemp.CS.UCLA.EDU>
Date: 7 Dec 88 01:43:37 GMT
References: <1039@desert.megatest.UUCP>
Sender: news@CS.UCLA.EDU
Reply-To: gast@cs.ucla.edu (David Gast)
Organization: UCLA Computer Science Department
Lines: 67

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