Path: utzoo!utgpu!watmath!clyde!att!cuuxb!dlm
From: dlm@cuuxb.ATT.COM (Dennis L. Mumaugh)
Newsgroups: comp.unix.wizards
Subject: Re: fixing rm * (was: Worm/Passwords)
Summary: it goes in the shell
Keywords: glob
Message-ID: <2212@cuuxb.ATT.COM>
Date: 19 Nov 88 17:15:49 GMT
References: <22401@cornell.UUCP> <4627@rayssd.ray.com> <8563@rpp386.Dallas.TX.US> <125@embossed.UUCP> <672@quintus.UUCP> <1232@atari.UUCP> <684@quintus.UUCP>
Reply-To: dlm@cuuxb.UUCP (Dennis L. Mumaugh)
Organization: ATT Data Systems Group, Lisle, Ill.
Lines: 38

This dicussion surfaces  at  least  once  every  6  months.  Gene
Spafford  out  to  summarize  and  put  into  the  100  questions
document:

In a job a long time ago in a place far, far away  ....  Four  of
us  got  bit by the rm * problem within two days.  I lost a whole
day's worth of power coding  and  had  to  reconstuct  an  entire
project  from  memory  [see  Knuth  on the merits of this] when I
typed rm *.c instead of rm *.o.

So, I decided there must be a better way.  Since we  also  had  a
set  of  other  similar  commands  [del and delete for the PDP-10
lovers] we built a trap door into the shell.  If the command  was
exactly  {rm|del|delete}  and  the  glob function returned a true
[expanded a * ? or  [  ...]  construct]  we  echoed  out  to  the
terminal  the  expanded  form  of  the  command  and a request to
confirm.

e.g the command 
	rm *.c
whould result in
	glob: rm foo.c bar.c barf.c fubar.c unix.c 
	confirm?  

The query would only be echoed  if  the  stdin  was  a  terminal.
Also,  it  worked ONLY with simple command names, full path names
or alias expansions weren't checked.

We also got bit later by the following:
	rm -rf ..
So we had to put a check into rm for that kind of combination.

Yes, we did get a few people who would hit y<CR>  by  habit.  But
only  until  they  did  it  one  too many times.  After that they
learned.
-- 
=Dennis L. Mumaugh
 Lisle, IL       ...!{att,lll-crg}!cuuxb!dlm  OR cuuxb!dlm@arpa.att.com