hansm@cs.kun.nl (Hans Mulder) (03/28/91)
In article <1991Mar25.191821.11019@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu (Pierre Lewis) writes: >1) vi commands :w :q and :n > > With the vi on our SunOS 4.0.3, I can do the following: > :w to write back a file > :q to quit the editor > :wq to write back a file AND quit the editor > > I can also do: > :n to move to next file (if current file has no pending changes) > [ ... so he tried... ] > :wn > and got the message "wn: Not an editor command". There is surely some > other command that will do it, but why not the intuitive choice? The :wq command was a mistake and should be expelled from vi ASAP. For one thing, it invites the mistake Pierre described above. Plus, the :x command is superior: - it skips the write if the buffer was not [Modified] - it gives you a second chance if the write failed - it's shorter :-) - ZZ is mapped to :x. By the way, Pierre, the trick to get two ex commands on a line is to separate them by a |, e.g.: :w|n But :g and :! commands can have |s in their arguments, so they must be the last command on the line. If you find yourself typing :w|n all the time, you might want to :set autowrite and use :n! on those rare occasions when you don't want to save changes. Keep in mind that vi also autowrites when you stop it using ctrl-Z, use :stop! if you don't want to autowrite before stopping. Have a nice day, Hans Mulder hansm@cs.kun.nl
Dan_Bloch@TRANSARC.COM (03/28/91)
hansm@cs.kun.nl (Hans Mulder) writes: > If you find yourself typing :w|n all the time, you might want to > :set autowrite > and use :n! on those rare occasions when you don't want to save changes. No! With autowrite set, :n! does exactly the same thing as :n. Dan Bloch dan@transarc.com
dattier@vpnet.chi.il.us (David W. Tamkin) (03/28/91)
hansm@cs.kun.nl (Hans Mulder) wrote in <2900@wn1.sci.kun.nl>: | The :wq command was a mistake and should be expelled from vi ASAP. | For one thing, it invites the mistake Pierre described above. | Plus, the :x command is superior: | - it skips the write if the buffer was not [Modified] That alone would be reason to use :wq, except that in the versions of vi I've used, :wq also skips the write if the [Modified] flag is off; I have to use :w and then :q to get around it. Even setting autowrite and writeany doesn't help. If only vi didn't clear the [Modified] flag when you write to an outside file; that's the real problem. | - it gives you a second chance if the write failed It does? I didn't know that. The only time a write ever failed on me the whole system locked up and I lost all my changes anyway, and I wasn't trying to quit vi, just to :w to save the changes so far. | - ZZ is mapped to :x. That ZZ is mapped to :x doesn't make :x superior; it means only that someone else before Hans felt that :x was superior to :wq. David Tamkin PO Box 7002 Des Plaines IL 60018-7002 dattier@vpnet.chi.il.us GEnie:D.W.TAMKIN CIS:73720,1570 MCIMail:426-1818 708 518 6769 312 693 0591 "Parker Lewis Can't Lose" mailing list: write flamingo-request@ddsw1.mcs.com
dberg@informix.com (David I. Berg) (03/30/91)
In article <2900@wn1.sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes: >In article <1991Mar25.191821.11019@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu (Pierre Lewis) writes: >>1) vi commands :w :q and :n >>........ > >The :wq command was a mistake and should be expelled from vi ASAP. > >For one thing, it invites the mistake Pierre described above. >Plus, the :x command is superior: >- it skips the write if the buffer was not [Modified] >- it gives you a second chance if the write failed >- it's shorter :-) >- ZZ is mapped to :x. Let me tell you about ZZ. Once upon a time a system crashed during a long and arduous edit session. When the system came back up, I successfully recovered my file with vi -r, but had other things to do just then, so I autumatically entered ZZ and went on with my business. Because ZZ had become such an autonomous keystroke, it never occurred to me that because I had not modified the buffer during the vi -r session the file would't be saved. Later, when I went back to edit my file, guess whose prior arduous changes were conspicuous by their absence. I have never used ZZ since, will never use it in the future, and thank vi for :wq. ___ ___ dberg@cougar.informix.com / ) __ . __/ /_ ) _ __ Informix Software Inc. (303) 850-0210 _/__/ (_(_ (/ / (_(_ _/__> (-' -/~ (_- 5299 DTC Blvd #740; Englewood CO 80111 {uunet|pyramid}!infmx!dberg The opinions expressed herein are mine alone.
les@chinet.chi.il.us (Leslie Mikesell) (03/30/91)
In article <1991Mar28.155305.8204@vpnet.chi.il.us> dattier@vpnet.chi.il.us (David W. Tamkin) writes: >That alone would be reason to use :wq, except that in the versions of vi I've >used, :wq also skips the write if the [Modified] flag is off; I have to use >:w and then :q to get around it. Even setting autowrite and writeany doesn't >help. If only vi didn't clear the [Modified] flag when you write to an >outside file; that's the real problem. Actually there is an easy work-around for this. Just remember to do a :w <enter> before you :w other_file. That keeps the file consistent with the modified flag. [:x] >| - it gives you a second chance if the write failed >It does? I didn't know that. The only time a write ever failed on me the >whole system locked up and I lost all my changes anyway, and I wasn't trying >to quit vi, just to :w to save the changes so far. It won't fix a system crash of course, but you can recover from things like not having write permission or file system full errors if you can save a copy somewhere else. :wq exits regardless. Les Mikesell les@chinet.chi.il.us
torek@elf.ee.lbl.gov (Chris Torek) (03/31/91)
In article <1991Mar29.160622.5445@informix.com> dberg@informix.com (David I. Berg) writes: >... Once upon a time a system crashed during a long and arduous edit >session. When the system came back up, I successfully recovered my >file with vi -r, but had other things to do just then, so I >autumatically entered ZZ and went on with my business. This is a bad idea, and not only because in some version of vi it does not write the file anywhere. You should *always* write recovered files to a new (temporary) name and compare the original and new files manually, as it is possible for recovered files to be partially mangled. In most cases, the recovered file will be correct, but in a few cases you can get back almost all of your work only by merging the original and new files. -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov
dik@cwi.nl (Dik T. Winter) (03/31/91)
In article <11638@dog.ee.lbl.gov> torek@elf.ee.lbl.gov (Chris Torek) writes: > In article <1991Mar29.160622.5445@informix.com> dberg@informix.com > (David I. Berg) writes: > >... Once upon a time a system crashed during a long and arduous edit > >session. When the system came back up, I successfully recovered my > >file with vi -r, but had other things to do just then, so I > >autumatically entered ZZ and went on with my business. > > This is a bad idea, and not only because in some version of vi it does > not write the file anywhere. You should *always* write recovered files > to a new (temporary) name and compare the original and new files > manually, as it is possible for recovered files to be partially > mangled. In that case I would say the design is wrong. Things that users naturally do (entering ZZ, and I have done it also a few times), do not what is expected. I think it would be better to have a single recover file command that would replace 'vi -r', 'ex -r', and friends. As for the partially mangled bit: if this does occur that is also bad design. There is no reason at all that an aborted edit session would leave a mangled internal file. (Yes, I did an editor on a Cyber. The system was able to crash frequently. All I would ever loose were the results of the last few commands entered.) -- dik t. winter, cwi, amsterdam, nederland dik@cwi.nl
noraa@cbnewsk.att.com (aaron.l.hoffmeyer) (04/01/91)
In article <1991Mar29.160622.5445@informix.com> dberg@informix.com (David I. Berg) writes: >In article <2900@wn1.sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes: >>In article <1991Mar25.191821.11019@scrumpy@.bnr.ca> bnrmtl!lewis@larry.mcrcim.mcgill.edu (Pierre Lewis) writes: > >>>1) vi commands :w :q and :n >>>........ >> >>The :wq command was a mistake and should be expelled from vi ASAP. >> >>For one thing, it invites the mistake Pierre described above. >>Plus, the :x command is superior: >>- it skips the write if the buffer was not [Modified] >>- it gives you a second chance if the write failed >>- it's shorter :-) >>- ZZ is mapped to :x. > >Let me tell you about ZZ. Once upon a time a system crashed during a >long and arduous edit session. When the system came back up, I >successfully recovered my file with vi -r, but had other things to >do just then, so I autumatically entered ZZ and went on with my business. >Because ZZ had become such an autonomous keystroke, it never occurred >to me that because I had not modified the buffer during the vi -r >session the file would't be saved. Later, when I went back to edit my >file, guess whose prior arduous changes were conspicuous by their absence. >I have never used ZZ since, will never use it in the future, and thank vi >for :wq. > ___ ___ dberg@cougar.informix.com > / ) __ . __/ /_ ) _ __ Informix Software Inc. (303) 850-0210 >_/__/ (_(_ (/ / (_(_ _/__> (-' -/~ (_- 5299 DTC Blvd #740; Englewood CO 80111 >{uunet|pyramid}!infmx!dberg The opinions expressed herein are mine alone. The same thing happened to me in 1987 - the last I used ZZ also. I tell everyone to use :wq or :w or :q or :next or :rewind etc. - tell vi exactly what you want to do. No ZZ for me, thank you. Yes :wq is three keystrokes, and ZZ might be faster, but I actually think about the :wq when I type it. I often edit 10 files or more at a time, so I don't want to write and quit, I just want to write and move to the next file. Aaron L. Hoffmeyer TR@CBNEA.ATT.COM
aden@vf.jsc.nasa.gov (04/02/91)
>In article <1991Mar28.155305.8204@vpnet.chi.il.us>, dattier@vpnet.chi.il.us (David W. Tamkin) writes: >> hansm@cs.kun.nl (Hans Mulder) wrote in <2900@wn1.sci.kun.nl>: >> | - it gives you a second chance if the write failed >> >> It does? I didn't know that. The only time a write ever failed on me the >> whole system locked up and I lost all my changes anyway, and I wasn't trying >> to quit vi, just to :w to save the changes so far. I believe he was trying to point out a permissions problem scenario, i.e. you use :x in a directory where you haven't permission, and it'll tell you the file was read-only and not exit. :wq will quit anyway, I believe. -Spenser -- S. Spenser Aden -- Lockheed Engineering and Sciences Co. -- (713) 483-2028 NASA -- Johnson Space Center, Houston -- Flight Data and Evaluation Office aden@vf.jsc.nasa.gov -- Comments are mine alone, not those of LESC or NASA.
peter@ficc.ferranti.com (Peter da Silva) (04/02/91)
In article <1991Apr1.094106.26188@cbnewsk.att.com> noraa@cbnewsk.att.com (aaron.l.hoffmeyer) writes: > The same thing happened to me in 1987 - the last I used ZZ also. I tell > everyone to use :wq or :w or :q or :next or :rewind etc. - tell vi > exactly what you want to do. But that's what I want VI to do: write the file if it's modified, then exit. I often move around between files without modifying them, and don't want to write them (and thus touch them for "make"s viewpoint) if I haven't changed them. When I *do* a vi -r I write to a new file name anyway. -- Peter da Silva. `-_-' peter@ferranti.com +1 713 274 5180. 'U` "Have you hugged your wolf today?"
rca@ingres.com (Bob Arnold) (04/02/91)
In article <2900@wn1.sci.kun.nl> hansm@cs.kun.nl (Hans Mulder) writes: >The :wq command was a mistake and should be expelled from vi ASAP. > >For one thing, it invites the mistake Pierre described above. >Plus, the :x command is superior: >- it skips the write if the buffer was not [Modified] >- it gives you a second chance if the write failed >- it's shorter :-) >- ZZ is mapped to :x. As someone who's taught vi to a number of novice users, I'd say that :w and :q (and :wq) are much clearer about what's going on. -- __ _ _ Bob Arnold ASK / Ingres Product Division |/ \ / \ / \| 1080 Marina Village Parkway | / / | Alameda, CA, 94501 | \__/ \__/| rca@ingres.com 415/748-2819
dattier@vpnet.chi.il.us (David W. Tamkin) (04/03/91)
les@chinet.chi.il.us (Leslie Mikesell) wrote in <1991Mar29.162034.12996@chinet.chi.il.us>: | In article <1991Mar28.155305.8204@vpnet.chi.il.us> [I wrote]: | >If only vi didn't clear the [Modified] flag when you write to an | >outside file; that's the real problem. | | Actually there is an easy work-around for this. Just remember to do | a :w <enter> before you :w other_file. That keeps the file consistent | with the modified flag. That's the trick: remembering to :w <enter> first or, if you decide to make no more modifications, to make and undo a trivial one after :w <savefile> and before :wq or ZZ or :x. I learned that the hard way, after getting burned several times by it, learning about it only when regular correspondents, who knew I wasn't a nutcase, told me that mail they received from me consisted of exactly the text they had sent me, set off by citation characters. I couldn't figure out what the heck was undoing my editing until I hit on this problem with vi. | [:x] | >| - it gives you a second chance if the write failed | >It does? I didn't know that. The only time a write ever failed on me the | >whole system locked up and I lost all my changes anyway, and I wasn't trying | >to quit vi, just to :w to save the changes so far. | It won't fix a system crash of course, but you can recover from things | like not having write permission or file system full errors if you | can save a copy somewhere else. :wq exits regardless. The :w attempt *caused* the system crash. The disks were full to bursting (I hadn't learned about df yet; if I'd known, I'd have been ready for the risk and :%p'ed to capture the text in my own computer before trying to :w) and the system was already gasping; my :w attempt was the coup de grace. [Note to the poster named, I think, Hoffmeyer who said that he prefers :wq to ZZ even though three keystrokes are more than two: :wq requires <enter>, so it's actually four keystrokes. I imagine that you still prefer it.] David Tamkin PO Box 7002 Des Plaines IL 60018-7002 dattier@vpnet.chi.il.us GEnie:D.W.TAMKIN CIS:73720,1570 MCIMail:426-1818 708 518 6769 312 693 0591
torek@elf.ee.lbl.gov (Chris Torek) (04/04/91)
>In article <11638@dog.ee.lbl.gov> I noted: >>... You should *always* write [`vi -r'] recovered files to a new >>(temporary) name and compare the original and new files manually, >>as it is possible for recovered files to be partially mangled. In article <3234@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes: >I think it would be better to have a single recover file command >that would replace 'vi -r', 'ex -r', and friends. I agree (and this would be true even if recovery were infallible). >As for the partially mangled bit: if this does occur that is also bad >design. There is no reason at all that an aborted edit session would >leave a mangled internal file. To get this right, you must in essence duplicate a database transaction system; this is notoriously difficult and/or slow on conventional Unix machines. vi simply tries hard not to mangle text, but if you port BSD often enough%, you will eventually run `vi -r' only to see LOST LOST LOST on your screen.... ----- % This implies `use flaky pre-alpha systems', like the one that is not even debuggable yet on my SparcStation... I have not got past kernel startup yet, much less get ready to lose vi files. But I have hopes. :-) -- In-Real-Life: Chris Torek, Lawrence Berkeley Lab CSE/EE (+1 415 486 5427) Berkeley, CA Domain: torek@ee.lbl.gov