rcd@opus.UUCP (Dick Dunn) (10/09/84)
> Good grief! I thought that everyone had aliased "rm" to "mv". Huh?! Are we trying to solve the problem by ignoring it? > Try putting these lines in your .cshrc: > > # safe rm. moves things to /tmp, where the system can garbage collect > alias rm 'mv \!* /tmp/wunder' > > You are free to use your own login name instead of mine for your... This doesn't work well in the face of system crashes if your system works as ours does, in two respects: We don't have a lot of space in /tmp. Making everyone else's compilations (etc., etc.) bomb out so that you can have your own personal file wastebasket overflowing is not kindly regarded around here. We clean out /tmp on rebooting (as happens after a crash), so if the files you want to hang on to happen to be needed because of a crash while you were doing something, they'll all get blown away at the worst time. And, of course, there's the oops-I'm-in-the-wrong-directory routine--you go to clean up /tmp/myself only you space out the cd or some such and end up cleaning out your work directory. For most of the clever backup schemes, there's a standard screwup that will zorch them. In the end, there's no substitute for plain old common stupidity...er, I mean... -- Dick Dunn {hao,ucbvax,allegra}!nbires!rcd (303)444-5710 x3086 ...Relax...don't worry...have a homebrew.
bsa@ncoast.UUCP (Brandon Allbery) (10/11/84)
> Article <> From: rcd@opus.UUCP (Dick Dunn) +--------------- | > Good grief! I thought that everyone had aliased "rm" to "mv". | | Huh?! Are we trying to solve the problem by ignoring it? | | > Try putting these lines in your .cshrc: | > | > # safe rm. moves things to /tmp, where the system can garbage collect | > alias rm 'mv \!* /tmp/wunder' | > | > You are free to use your own login name instead of mine for your... | | This doesn't work well in the face of system crashes if your system works | as ours does, in two respects: | | We don't have a lot of space in /tmp. Making everyone else's | compilations (etc., etc.) bomb out so that you can have your own | personal file wastebasket overflowing is not kindly regarded around | here. | | We clean out /tmp on rebooting (as happens after a crash), so if | the files you want to hang on to happen to be needed because of a | crash while you were doing something, they'll all get blown away at | the worst time. | | And, of course, there's the oops-I'm-in-the-wrong-directory routine--you go | to clean up /tmp/myself only you space out the cd or some such and end up | cleaning out your work directory. For most of the clever backup schemes, | there's a standard screwup that will zorch them. In the end, there's no | substitute for plain old common stupidity...er, I mean... Hmmm, 'alias rm rm -i; alias remove /bin/rm' is 9/10 of the problem. Of course, you can still foul it up... and since I also sometimes mess up a file in the editor, I have a vi front-end to create .B:files in the directory where the file I'm editing is. Only one backup is kept per file. And it's relatively difficult to delete .B:* without knowing you've fouled up (rm .* will yell about removing .. and . long before it gets that far). The /tmp soulution is out; until just recently, we had the following disk space allocation: /dev/root - 12M (also /tmp and /dev/swap) /dev/hd1 - 8M /dev/fd0 - 1.2M /dev/fd1 - 1.2M -the latter being floppies that might not be mounted or might be only single-sided for .6M. There was barely enough room for my .B:file backups, much less /tmp/bsa. On the system I describe above (at work), I use both schemes. On the system I'm writing from (hobby system, tdi1 isn't on the net) I only use the rm alias. I lose too much with the other -- it isn't smart enough to allow 'vi +5 file' or such -- maybe I'll hack a copy of vistart as provided in net.sources a while back. --bsa