fixing rm * (was: Worm/Passwords)

[Juergen Wagner]

In article <723 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>...
>A very common practice may never-the-less be a bad idea.

I agree 100%.

>...
>want to protect beginners from the dangerous commands, give them aliases
>which flat-out refuse to do anything at all:
>	alias rm 'echo "Use \"delete\" to delete files; rm is dangerous."'

That's a good idea, too. But it aliases "rm", so it no longer doesn what the
manual says, ...and beware of shell scripts using this kind of rm.

>...
>The other effect is that the commands available to the beginner no longer
>match the documentation; how anyone can perceive that as good is beyond me.

Hmmm... I think, it's the other way round. Documentation should match the
tools!

>...
>No, it is _not_ a bad example.  If I "alias ls 'ls -F'", I am likely to
>use it in a script which _relies_ on that behaviour.  Then I give it to
>someone else and it doesn't work.  THIS KIND OF THING **HAPPENS**.
>...

People writing shell scripts must not rely on such thinks. If I am writing
a safe shell script, I am either disallowing .cshrc to be read, or giving
pull paths of the commands, or unalias'ing the commands before using them.
People writing shell scripts should do that for the very reason to be
compatible because some users may have weird aliases which are breaking
code.

>...
>		  If you are using someone else's account, you haven't
>ANY IDEA *AT ALL* what rm does until you have checked for aliases and
>shell functions.

Right! Before I am executing destructive operations, I am checking that.

>...
>			  I tell you what, someone who writes C code can
>do a lot of silent and destructive stuff.  Let's protect users against
>this by making sure they can't use the C compiler.  (And we must keep
>them away from perl, or the poor little simpletons will get into real
>trouble.  And we had better disable ">", so let's set noglob and noclobber
>in everyone's .cshrc.)

"set noclobber" is a good idea but it will only work in csh, right? As for
the guys writing C code to silently erase a user's files, I wouldn't say
they are beginners, would you? Someone writing such code should know what
he/she is doing. No operating system can be fool-proof without being trivial.

>If you want a shell which tries to protect people from themselves, is
>verbose, and is widely liked, there are at least two implementations
>of DEC's DCL command language for UNIX.

Widely liked? Humph!

VMS isn't foolproof, either (although it would like to be).

>Or you could do what Sun are starting to do in SunOS 4.0, and give people
>mouse-oriented tools for deleting files &c.  Giving people an easy way of
>deleting files by clicking on an icon makes thing safer for them without
>taking anything at all away.  Emacs "DIRED" mode is the same kind of
>safety-through-convenience approach.

Coming closer! That's my idea of a user-friendly interface. An "undo"
operation should be an essential part of the user interface... but that
will remain utopical for most UNIX systems for the time being, I am afraid.
(why not use a LISP machine :-) ).

---
-- 
Juergen Wagner		   			gandalf at csli.stanford.edu
						 wagner at arisia.xerox.com