Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!sq!msb
From: msb@sq.UUCP
Newsgroups: comp.cog-eng,comp.unix.xenix,comp.unix.wizards
Subject: Re: Request for human interface design anecdotes (and a cure?)
Message-ID: <1987Nov21.014754.19660@sq.uucp>
Date: Sat, 21-Nov-87 01:47:54 EST
Article-I.D.: sq.1987Nov21.014754.19660
Posted: Sat Nov 21 01:47:54 1987
Date-Received: Sun, 22-Nov-87 09:19:51 EST
References: <3103@psuvax1.psu.edu>
Reply-To: msb@sq.UUCP (Mark Brader)
Organization: SoftQuad Inc., Toronto
Lines: 19
Xref: sq comp.cog-eng:294 comp.unix.xenix:1027 comp.unix.wizards:5188
Checksum: 07813
Summary: behavior of rm * considered desirable

> The rm * disaster catches not only the absent-minded ...

I thought it was about time someone expressed the opposite point of view.

If I type "rm *", it is because I want to remove all the files.  No, not
all *my* files.  All *the* files that I still have write permission on,
that are in the current directory.  Usually no more than about 20 of them.
In short, the proper UNIX* flavored method for protecting important files
from "rm" is to turn off the write permission bit.

Now, if you want to talk about human interface disasters and "rm" ...
Tell me how come "rm ... &" causes the -f flag to be assumed, and thus
removes the write-protected files after all?  Write-protecting the directory
stops it, but this is often not feasible.  I think the gods nodded on that one.

Mark Brader, utzoo!sq!msb, msb@sq.com		C unions never strike!

*"UNIX is a trademark of Bell Laboratories" is a religious incantation.
  That it no longer reflects reality is a bug in reality.