fixing rm * (was: Worm/Passwords)

[Richard A. O'Keefe]

In article <6518 at csli.STANFORD.EDU> wagner at arisia.xerox.com (Juergen Wagner) writes:
>In article <717 at quintus.UUCP> ok at quintus.UUCP (Richard A. O'Keefe) writes:
>>I do hope not.  It is a bad idea to define aliases for the standard
>>commands (and if you are a system administrator, giving new users 
>>profiles with such redefinitions in them is _extremely_ bad manners).
>
>Redefining "rm" as "rm -i", "mv" as "mv -i", and "cd" et al. to the prompt-
>changing versions is *VERY* common practice, I think. System administrators
>do not put these into the .cshrc to surprise people, they are there to help
>beginners to start in a safe environment (at least safer than without these
>definitions), without having to worry about mistakenly typing "rm foo/ *".

A very common practice may never-the-less be a bad idea.
It is no service to beginnners to give them an alias WHICH DOES NOT MATCH
THE DOCUMENTATION.  By all means, provide a "del" or "delete" command
which is safe, and a "move" or "rename" command which is safe, but if you
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."'

System administrators may not _intend_ to surprise people with their
redefinitions, but that is one of the effects they do in fact produce.
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.

>>For example, I very much like the "-F" option in ls, but it would be
>>incredibly stupid to "alias ls 'ls -F'".  Instead I "alias lf 'ls -AF'"
>>and use "lf".  Just so, if you don't like what rm does, _leave_it_alone_
>>and define yourself an alias, script, C program, or whatever, called
>>"del", "delete", "delf", or whatever takes your fancy, and use that.
>
>Bad example.
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**.  But
if I use "lf" in my script, then the other user is going to be told that
there isn't any such command.

>As for non-csh shells, how about "rm () { /bin/rm -i $* }" as an 'alias' for
>"rm".

Well, that's nice for you, but many of the machines that I use do not
support Bourne shell functions.  I get
	syntax error: `(' unexpected
when I try that.  (We have Suns running 3.x and 4.x, which support shell
functions, but also Suns running 2.x, which don't, and several other
machines running 4.2BSD.  What is *really* confusing is the machines
which offer two "universes", where shell functions work in one universe
but not the other.  My .profile has to work under _all_ of these.)

>As a consultant, I am also working under other peoples accounts. If I am just
>fixing something, I simply do not rely on "rm" being aliased.

No, that's not the problem.  The problem is that you can't rely on it NOT
being aliased.  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.  Especially with the "rm" aliases which copy files
someone else, if you issue an "rm" command to delete a file that you have
just created, you cannot rely on that not destroying a file that the real
user was hoping to keep.  I for one am sick of having to type \rm.

>However, it is desirable to protect new users against the unwanted effects of
>some silent and destructive commands, so I would put the respective aliases
>into new users .*rc file.

I repeat: it is ok to alias a standard command so that it refuses to do
anything at all, and makes it plain that it has not worked.  But it is
a bad idea to make a command _do_ something, but not _exactly_ what is
described in the manual.  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.)

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.

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.