NOTE: This page is not about bugs for vi clones; the vi clones usually have a webpage, free source code, and supporters, so bugs usually get squashed pretty soon. It simply makes no sense to keep descriptions of their old bugs around.
Assume you started vi with "vi foo". Make some changes. Save the changes to the file with ":w" if you like.
Make some more changes. But this time, before you write the buffer to the file again (eg with ":w") make an intermediate "backup" to some other file, say, to file "bar", ie use command ":w bar".
The bug is that vi cancels the modified flag on the current buffer as if you had done ":w" and foo were updated with the changes.
So when you leave vi at that point with a write command (":x", ":wq", or "ZZ") vi will NOT write the buffer to the file foo as the "modified" flag is (incorrectly) OFF - even though you *have* made changes to its copy in the edit buffer. :-(
NOTE: This frequently happens to people who use vi to write a mail (or a post) and use ":w foo.copy" to save a copy of the mail. When they send off the mail after exiting vi they thus send off the version that was last saved before the extra copy. And if they never saved the mail during the edit session then they send off an empty mail. :-(
Thanks to David W. Tamkin for explaining this to me!
Bug or feature? You decide.
"on older Solaris versions (Version SVR4.0, Solaris 2.5.0), you get easily segmentation fault with bad input, e.g. try ":f^V^M^M")."
Confirmed.
echo foo | viHere you would expect VI to open a buffer with "foo" in it. But eg Vi-SVR3 exits with the message "Input read error". :-(
However, Vi Clones do accept data from stdin. Example:
echo foo | vim -
However, Vi does not allow a number prefix for these commands:
/ search forward ? search backward n search for next occurrence of last used search pattern in same search direction N search for next occurrence of last pattern in opposite search direction p put contents of unnamed register after current char/line p put contents of unnamed register before current char/line
Example:
Preparation: Enter a line with "foo" with the command "ofooESC". Now copy the line with 'Y' and try to put two copies after it with "2p".
Result: Only one copy will be inserted - instead of two.
Workaround: Use the "ex command" (aka "command line") to "put" as it can take a number prefix. You can apply this to an "global" command, too.
Example:
1,L/^/McoN^MThis command jumps to line L, makes M copies of it, and puts them after line N.
Remark: Thank God this is fixed with vi clones! :-)
Example: The command
2iabc^Mxyz^[will make Vi apply the '2' only for the line "abc" - and immediately after pressing ^M. However, the number prefix then is considered to "has been used" and will thus not be used for further text. So the line with "xyz" will not be duplicated.
Result:
abc abc xyz[980105]
When Vi-SVR3.1 starts up on an exrc with an empty line you get the error message "No lines in the buffer" twice.
Fix: Do NOT use empty lines in your exrc! ;-)
Workaround: Put a '"' at the beginning of the line instead thus making the line a comment. You can insert an empty line to disable the rest of the exrc on purpose, of course. ;-)
Now, the weird thing is that when you explicitly read in the setup file, eg with ":source .exrc" then the line after the empty *will* be processed.
Thanks to
Jason Carr
http://www.mousetrap.net/~mouse/
for the hint on this.
[970710]
SunOS: Version SVR3.1 Solaris 2.5.0: Version SVR4.0 Digital Unix: Revision: 4.3.8.2 $ $Date: 1993/06/10 19:42:30 $ Digital Unix: Revision: 4.3.15.2 $ $Date: 1995/06/12 19:52:40 $ AIX 4.1.x: no error HP-UX 8.00: no errorinfo by Matthias Buelow token@altair.franken.de
Command sequence: mdoESCc'd
Result: Makes Vi segfault.
Reported by: W-J. Kasdorp wkasdo@nikhefk.nikhef.nl on comp.editors [970121]
For this command sequence to work there must be a match for the command % . This needs some preparation:
"I have verified this bug on a number of standard implmentations
including Solaris, HP/UX, DG/UX, Unixware, and others I can't recall
right now. VIM does not have the same behavior as VI in this instance."
[961021]
Submitted by: Jonathan A. George jgeorge@cftnet.com
Unconfirmed.
Please include the version info with any reports, ie the string given by the command ":version" (":ver"). Thanks!