thaeler@hc.DSPO.GOV (Bret K. Thaeler) (11/18/87)
Try the following: % cp .login goo % view goo {inside vi} :w>> goo you have just appended to a file you opened Read Only.... BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG -Bret Thaeler (thaeler@hc.dspo.gov)
decot@hpisod2.UUCP (11/19/87)
> Try the following: > % cp .login goo > % view goo > {inside vi} > :w>> goo > > you have just appended to a file you opened Read Only.... > > BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG > Not only that! You can also do: :!/bin/rm -f goo and the file will be GONE! OH NO! If you don't get the sarcasm, this is a feature. Dave
pmontgom@sdcrdcf.UUCP (11/20/87)
In article <11323@hc.DSPO.GOV> thaeler@hc.DSPO.GOV (Bret K. Thaeler) writes: > % cp .login goo > % view goo > {inside vi} > :w>> goo >you have just appended to a file you opened Read Only.... Relatedly, if goo is read only and you do % vi goo (edits) ZZ then it won't let you write there, even after you do a control-Z and a chmod. -- Peter Montgomery pmontgom@sdcrdcf.UUCP Don't blame me for the crowded freeways - I don't drive.
siegel@hc.DSPO.GOV (Josh Siegel) (11/20/87)
In article <16660001@hpisod2.HP.COM> decot@hpisod2.HP.COM (Dave Decot) writes: >> Try the following: >> % cp .login goo >> % view goo >> {inside vi} >> :w>> goo >> >> you have just appended to a file you opened Read Only.... >> >> BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG BUG >> > >Not only that! You can also do: > > :!/bin/rm -f goo > >and the file will be GONE! OH NO! > >If you don't get the sarcasm, this is a feature. I think vi should check to see if you are appending to the current file. If I do a view o.c :w>> and hit return, I specificly specified to append to the current file. Problem was that it was read only. Why don't you get your head out of the sand and look at what he posted. --Josh Siegel -- Josh Siegel (siegel@hc.dspo.gov) Friends don't let Friends eat Cherry Zingers
cory@upba.UUCP (11/23/87)
":w" is a feature of vi that writes the file. You can follow the write command with a file name to write to, or ">", ">>", or "|". (Is that all or are there other allowed operators?) When using the pipe sign, you are effectively using the shell, and it is out of vi's hands. When using ">" or ">>" you are sending a current copy of the file being edited (we will call this file1) to or appended to the file named after the greater- than sign(s) (let's call this file2). Vi really doesn't care what file2 is; if the file exists and you have write permission, Shazam; if the file does not exist and you have write permission in the directory, Shazam. Just because you choose to append to a file that you have write access to, but happen to be editing in read-only mode, makes no difference. file1 and file2 are NOT related, and whether or not they are the same file doesn't matter. It's not a bug. -Cory ...!ihnp4!upba!cory (Cory Dekker @ United Phone Book Advertisers)| DISCLAIMER: Work: 1221 N St, Suite #800; Lincoln, NE 68508 {Ph: 402-476-2200}| You get what Home: 800 Foxcroft Ct, #188; Lincoln, NE 68510 {Ph: 402-483-7761}| you pay for!
bostic@ucbvax.BERKELEY.EDU (Keith Bostic) (11/24/87)
In article <4967@sdcrdcf.UUCP>, pmontgom@sdcrdcf.UUCP (Peter Montgomery) writes: > Relatedly, if goo is read only and you do > > % vi goo > (edits) > ZZ > > then it won't let you write there, even after you do a control-Z and a chmod. Yes, but ":w! goo" will allow you to overwrite it. The obvious problem with vi checking the mode each time you attempt to write the file is the semantics of someone else changing the mode of a file while you're editing it. --keith
siegel@hc.UUCP (11/24/87)
In article <50100001@upba> cory@upba.UUCP writes: > > [ . . .] > than sign(s) (let's call this file2). Vi really doesn't care what > file2 is; if the file exists and you have write permission, Shazam; > if the file does not exist and you have write permission in the > directory, Shazam. > > Just because you choose to append to a file that you have write > access to, but happen to be editing in read-only mode, makes no > difference. file1 and file2 are NOT related, and whether or not > they are the same file doesn't matter. It's not a bug. > > -Cory The real problem here is that a person open's a file using 'view', he is still capable of damaging the file without specificly requesting to do so. When I do ':w>><return>', I made the mistake of not specifying the file. It should have returned that it was read only. Even with all the problems that happen due to symbolic links, this check should be quick and easy. ':w' gets it right.. Why doesn't ':w>><RETURN>'? --Josh Siegel -- Josh Siegel (siegel@hc.dspo.gov) Friends don't let Friends eat Cherry Zingers
authorplaceholder@upba.UUCP (11/24/87)
/* Written 4:56 pm Nov 23, 1987 by hc.UUCP!siegel in upba:comp.bugs.4bsd */ >In article <50100001@upba> cory@upba.UUCP writes: >> Just because you choose to append to a file that you have write >> access to, but happen to be editing in read-only mode, makes no >> difference. file1 and file2 are NOT related, and whether or not >> they are the same file doesn't matter. It's not a bug. >> >> -Cory > >The real problem here is that a person open's a file using 'view', >he is still capable of damaging the file without specificly requesting >to do so. > >When I do ':w>><return>', I made the mistake of not specifying the file. > > --Josh Siegel I'll agree that when using "view", having "w>" (or "w>>") default write (or append) to the current file goes against the concept of "view"ing the file in read only. However, on our system atleast, "view" is just a link to "vi", and as I stated, in "vi" this is not a bug. Maybe to handle this special case, if a flag were set if argv[0] matched "view"?... Anyway, the original question was presented with file2 given; and as such, view or vi, "it's not a bug ... it's a feature". -Cory
siegel@hc.DSPO.GOV (Josh Siegel) (11/25/87)
In article <50100002@upba> cory@upba.UUCP writes: > >>When I do ':w>><return>', I made the mistake of not specifying the file. > > I'll agree that when using "view", having "w>" (or "w>>") default > write (or append) to the current file goes against the concept of > "view"ing the file in read only. However, on our system atleast, > "view" is just a link to "vi", and as I stated, in "vi" this is not > a bug. Maybe to handle this special case, if a flag were set if > argv[0] matched "view"?... Actually, since it already checks 'view' against argv[0], they can just check to see if it is read_only and then they know if it used view (or specificly set it to be read_only). We always get back to this case.... > > Anyway, the original question was presented with file2 given; and > as such, view or vi, "it's not a bug ... it's a feature". Correct, and since he specificly specified file2 in his posting, I guess I must submit. (sob snif...) You have struck the final blow :-) > > -Cory --Josh -- Josh Siegel (siegel@hc.dspo.gov) Friends don't let Friends eat Cherry Zingers