Path: utzoo!attcan!uunet!husc6!mailrus!purdue!decwrl!labrea!sri-unix!quintus!ok From: ok@quintus.uucp (Richard A. O'Keefe) Newsgroups: comp.unix.wizards Subject: Re: fixing rm * (was: Worm/Passwords) Message-ID: <723@quintus.UUCP> Date: 23 Nov 88 03:19:38 GMT References: <1812@ndsuvax.UUCP> <717@quintus.UUCP> <6518@csli.STANFORD.EDU> Sender: news@quintus.UUCP Reply-To: ok@quintus.UUCP (Richard A. O'Keefe) Organization: Quintus Computer Systems, Inc. Lines: 84 In article <6518@csli.STANFORD.EDU> wagner@arisia.xerox.com (Juergen Wagner) writes: >In article <717@quintus.UUCP> ok@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.