rwl@uvacs.UUCP (Ray Lubinsky) (10/28/86)
> 2) Why does 'vi -r file' not set the 'dirty bit' (or whatever it's called) > so that an immediate exit with ZZ will save the file. I lost some > changes after a crash because I had to leave and in my haste just > entered vi (ala above) and exited with ZZ. This did not save my file. > I think it should have. Any thoughts? > I had a professor here ask me the same question, hoping that I would ``fix'' vi(1) so that it would automatically write a recovered file with ``ZZ'' (even though ``vi -r'' is documented as behaving as it does). Just as I was diddling with a copy of one of the source files, the system crashed. When we came back up, I got mail saying that the edit buffer had been saved, even though I had just written the file a few minutes before the crash. Rather than just overwrite what I had, I did a diff on my most recent version and the version saved by vi(1)... Sure enough, *my* version was more up-to- date than the saved buffer. Perhaps you'll see as I did that you don't want an automatic write on recovery; if it had automatically ``updated'' my file, I would have been robbed of my most recent version. Why does ``vi -r'' do what it does? Because you *need* to evaluate whether the saving of the edit buffer was successful or not. I guess that the problem comes in making the recovery of a saved buffer look just like a regular edit session when, in fact, it shouldn't be. -- | Ray Lubinsky Department of Computer Science, University of Virginia | | INTERNET: rwl@uvacs.cs.virginia.edu | | CSNET: rwl%virginia@csnet-relay | | UUCP: ...!cbosgd!uvacs!rwl |
jay@isis.UUCP (Jay Batson) (10/31/86)
In article <843@uvacs.UUCP> rwl@uvacs.UUCP (Ray Lubinsky) writes: >> 2) Why does 'vi -r file' not set the 'dirty bit' (or whatever it's called) >> so that an immediate exit with ZZ will save the file. I lost some >> changes after a crash because I had to leave and in my haste just >> entered vi (ala above) and exited with ZZ. This did not save my file. >> I think it should have. Any thoughts? > > Just as I was diddling >with a copy of one of the source files, the system crashed. When we came back >up, I got mail saying that the edit buffer had been saved, even though I had >just written the file a few minutes before the crash. > >Rather than just overwrite what I had, I did a diff on my most recent version >and the version saved by vi(1)... Sure enough, *my* version was more up-to- >date than the saved buffer. > >Why does ``vi -r'' do what it does? Because you *need* to evaluate whether the >saving of the edit buffer was successful or not. This last sentence is the key. I have callus-interruptus (call-waiting) on my phone. When I've dialed in to a system, and the interruption happens, vi will sometimes save garbage as I'l logged off - something like a file full of control characters with none of the text I've written. Has to do I imagine with the clicks that callus-interruptus makes to the system when it happens. In that case, I certainly don't want vi to save that crap to the detriment of my original text. I may have an sccs or rcs file around to get a decent version from, but if I've made lots of changes since I got one last, I'd be out of luck if vi did what was originally asked here. One day I guess I'll figure out a good place to call-forward calls to before I get on the modem, and maybe stop this interruption problem. Oh well, the hazards of being paranoid about missing an important call.... -------- "Stop it!! Stop it now. This is getting silly again, and this silliness has _got_ to stop. Go on to the next sketch. Go on. Turn this camera o " Jay Batson ihnp4!onecom!\ isis!jay seismo!{hao,nbires}!/