Path: utzoo!attcan!uunet!munnari!otc!metro!ditsyda!megadata!alex
From: alex@megadata.oz (Alex Danilo)
Newsgroups: comp.unix.wizards
Subject: Re: fixing rm * (was: Worm/Passwords)
Summary: rm * (fundamental fix - no patches)
Message-ID: <322@megadata.oz>
Date: 24 Nov 88 07:33:28 GMT
References: <22401@cornell.UUCP> <4627@rayssd.ray.com> <8563@rpp386.Dallas.TX.US> <1067@entropy.ms.washington.edu>
Organization: Megadata P/L, North Ryde, Sydney, Aust.
Lines: 26

In article <1067@entropy.ms.washington.edu>, charlie@mica.stat.washington.edu (Charlie Geyer) writes:
> Creeping featurism considered harmful.  Leave it alone.
> This is all very easy.  If you don't like rm(1) put
>   alias foo rm -i
> in your .cshrc or put a shell script foo in ~/bin
>   rm -i $*
> and use foo to remove files.
> 
This solution (& lots of others proposed) are just bodges that novice users
would learn about after the fateful 'rm * .o':-) They are also useless for
people who choose to use 'sh' instead of 'csh'.
A possibly better solution could be to destroy the utility 'rm' and make
it a built-in command in 'sh', 'csh' & 'ksh' just as 'cd' is built-in.
Whenever file(s) are removed using wildcards, the shell could simply relink
the file(s) to another unique & (almost) invisible name (i.e. prefixed by
'.') & maintain a linked list of original file names with associated hidden
name. The next command executed by the user may be either an 'unrm' or another
valid command. If 'unrm' was executed the files may simply be relinked &
restored, no harm done. Any other command (valid command that is, not a typo)
following the 'rm' can trigger the shell to unlink all the hidden file names
& achieve the same result as an intentional 'rm'. Perhaps the number of
commands that may be executed before an 'unrm' could be another environment
variable. This system is idiot-proof & saves those late night typing mistake
nightmares. The main drawback is the file space being used until the purge is
actually done. Any shell source hackers think this will slow it too much?
E PLURIBUS UNIX - alex@megadata.oz
D
D