ksb@j.cc.purdue.edu (Kevin Braunsdorf) (10/27/87)
Can anyone suggest a solution to the novice user's classic error message: % rm * .o rm: .o nonexistent % exit I have one: make rm read an environment variable "RM" for options (much as vi reads "EXINIT" before it reads the command line). Any better ideas? Send mail: I will post summary. Kevin Braunsdorf "Eak! Gack! Burph." ksb@j.cc.purdue.edu ihnp4!ee.ecn.purdue.edu!j.cc.purdue.edu!ksb
zemon@felix.UUCP (Art Zemon) (10/29/87)
In article <5715@j.cc.purdue.edu> ksb@j.cc.purdue.edu.UUCP (Kevin Braunsdorf) writes: >Can anyone suggest a solution to the novice user's classic error message: > > % rm * .o > rm: .o nonexistent > % exit % alias rm delete "Delete" is a program which renames the file instead of unlinking it. Delete simply prepends ".," so that the file doesn't show up when the user runs "ls". Then you run a skulker at night to clean up the deleted files. -- Art Z. -- -- Art Zemon By Computer: ...!hplabs!felix!zemon By Air: Archer N33565 By Golly: moderator of comp.unix.ultrix
dhesi@bsu-cs.UUCP (Rahul Dhesi) (10/30/87)
In article <11074@felix.UUCP> zemon@felix.UUCP (Art Zemon) writes: >% alias rm delete I strongly advise that rm not be aliased to anything else. Instead, create a new command such as del or delete. This way you will not be rudely surprised if you ever move to a different machine and expect the aliased rm to work as before. You will also avoid confusing any scripts that use rm instead of /bin/rm. In particular, aliasing rm to "rm -i" is dangerous. You will get used to typing "rm *" and selecting files. Then one day you will type "rm *" on a different system and delete all your files. Use a different command name and tell your users they can use rm as usual and take a risk, or use del and be safer. Let them choose. Here's my del script (4.3BSD only). #!/bin/csh -f #File deletion with options #Rahul Dhesi 1987/02/25 #revised 1987/02/26 if ($#argv < 1) then echo Usage: del file ... exit (1) endif foreach file ($*) again: set type='Delete ['`/usr/bin/file "$file"|/bin/sed -e 's/ / /g'`']? [Yes/No/List/Quit] ' switch ("$type") case '*o such file or*' echo "Could not find $file" goto nextloop breaksw case '*directory*' echo "Skipping $file because it is a directory" goto nextloop breaksw case '*mission denied*' echo "Skipping $file because access to it was denied" goto nextloop breaksw endsw ask: echo -n "$type" set ans=($<) switch ("$ans") case 'y' case 'Y' /bin/rm "$file" if (-e "$file") then echo "Sorry, $file could not be deleted" | \ /bin/sed -e 's/\([^ ]\)/_\1/g' | \ /usr/ucb/more else echo "File $file" has been deleted endif breaksw case 'n' case 'N' echo "Skipping $file" breaksw case 'l' case 'L' switch ("$type") case '*text*' case '*script*' echo '*****' "$file" '*****' /bin/cat -uv "$file" | /usr/ucb/more -10d breaksw case '*empty*' echo "***** File $file is empty *****" echo '<...empty...>' breaksw case '*link to*' echo "***** Searching for printable strings in $file ... ***" /usr/ucb/strings "$file" | /bin/cat -uv | /usr/ucb/more -10dl breaksw case '*zoo archive*' echo -n "***** Archive $file contains: *****" /usr/local/zoo l "$file" | /bin/cat -uv | /usr/ucb/more -10dl breaksw default echo "***** Searching for printable strings in $file ... ***" /usr/ucb/strings "$file" | /bin/cat -uv | /usr/ucb/more -10dl breaksw endsw echo '*****' goto again breaksw case 'q' case 'Q' exit default echo 'Please type the first letter: Y, N, L, or Q' goto ask breaksw endsw nextloop: end exit -- Rahul Dhesi UUCP: <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!dhesi
sunil@hpcllmv.HP.COM (Sunil Bhargava) (11/02/87)
Have a file by the name of -i in your directory. This will be the first file that will be passed to "rm" in case of an "rm *". "rm" will interpret this as the -i option and hence query before removal. This will not effect any other cases. You could alias "mkdir" to a command that will automatically insert the -i file when a directory en cs. O(non
rpd@apple.UUCP (Rick Daley) (11/02/87)
In article <1379@bsu-cs.UUCP>, dhesi@bsu-cs.UUCP (Rahul Dhesi) writes: > In article <11074@felix.UUCP> zemon@felix.UUCP (Art Zemon) writes: > >% alias rm delete > > I strongly advise that rm not be aliased to anything else. Instead, > create a new command such as del or delete. This way you will not be > rudely surprised if you ever move to a different machine and expect the > aliased rm to work as before. I couldn't agree more. When I was at UNH a few years ago, I learned quite a bit about maintaining a UNIX system. All I had to do was watch what the staff there did, and make sure never to do the same thing! They came up with the brilliant idea of setting up "friendly" accounts on the VAX they used to teach intro courses. Among other things, they aliased rm to be less severe. When the poor students moved into higher level courses, they moved to another VAX where accounts were not set up this way. Many students got burned because the safegaurds they were used to were no longer there. In general, it's a bad idea to use alias to change the semantics of an existing command. It only causes confusion when you use another machine or account that does not have the same environment. Rick Daley rpd@apple.UUCP
mouse@mcgill-vision.UUCP (der Mouse) (11/19/87)
In article <5715@j.cc.purdue.edu>, ksb@j.cc.purdue.edu (Kevin Braunsdorf) writes: > Can anyone suggest a solution to the novice user's classic error message: > > % rm * .o > rm: .o nonexistent Sure, use rm -f, that way it won't complain :-) :-) There's the one we use here. The rm program reads the current directory and figures out what * would expand to. If its argument list contains this list of files, and there are more than four or so files involved, it asks the user "are you sure you mean to remove all those files?" before doing so. There is an option to suppress this behavior, for use by shell scripts and people who know they said rm * and they meant it. This avoids the familiarity/fatigue factor of aliasing rm to rm -i (there are tales of people who type "rm *" and answer "yes" for every file on the list because they are so used to doing so). The question is asked only when appropriate. The check for "four or more files" is to avoid questions when removing just the last file in a directory, for example. Not perfect (eg, "rm foo/*>o") but it goes a long way. der Mouse (mouse@mcgill-vision.uViViV
gandalf@russell.STANFORD.EDU (Juergen Wagner) (11/24/87)
After this quite long discussion about "rm" and its various options,
possible extensions, and other features to be added, it seems to me
that all we need is a DWIM (Do What I Mean) as LISP machine users
know and love (:-) it. "Do what *I* mean" is (of course) a matter of
perspective - in fact, often the system does what *IT* means. Does
anybody out there have any references to such a beast? I am thinking
of an ish ("intelligent shell") doing filename completion based on the
search path, spelling correction on file/directory names, allow to edit
previously typed-in lines, redo commands in a simpler fashion than csh,
and other fancy things.
Please, respond by e-mail. I will post a summary.
--Juergen Wagner (gandalf@Russell.Stanford.edu)
Center for the Study of Language and Information, Stanford Universityrapin@bnrmtv.UUCP (Eric Rapin) (11/24/87)
In article <911@mcgill-vision.UUCP>,mouse@mcgill-vision.UUCP (der Mouse) writes: > > This avoids the familiarity/fatigue factor of aliasing rm to rm -i > (there are tales of people who type "rm *" and answer "yes" for every > file on the list because they are so used to doing so). The question > is asked only when appropriate. > der Mouse > > (mouse@mcgill-vision.uucp) And then there are those who alias rm to rm -i and then do things like: % yes | rm * Hard to stop once it gets going, but you do get to be suitably horrified watching it ask if it should remove files and then it mysteriously continues! I would agree with whoever suggested that aliasing rm to rm -i is dangerous, especially for people who change accounts and/or systems frequently. Somehow it is so easy to forget that rm only interrogates because you forced it to instead of doing it by default. (even though I do it myself, it seems to not be too dangerous since all my new accounts never have many files in them...at least not until I've discovered that I missed one of my favorite aliases :') I always find myself doing this: % \rm -f * when I REALLY know what I'm doing, otherwise I've forced myself into the habit of reading each file name before typing 'y'. It's a hard learned discipline that you should only need to learn once, but most of us hate to break habits... :') -- Eric B. Rapin UUCP: {3comvax,amdahl,ames,csi,hplabs}!bnrmtv!rapin Bell-Northern Research, Inc. ARPA: bnrmtv!rapin@ames.arpa Mountain View, California - Don't sweat it, it's only ones and zeros. -
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/26/87)
In article <791@russell.STANFORD.EDU> gandalf@russell.stanford.edu (Juergen Wagner) writes: >... I am thinking >of an ish ("intelligent shell") doing filename completion based on the >search path, spelling correction on file/directory names, allow to edit >previously typed-in lines, redo commands in a simpler fashion than csh, >and other fancy things. The BRL SVR2 Bourne shell is among those that do these things. (Except for the spelling corrector; I considered it but I don't think they do a good enough job, especially considering how easy it now is to edit previous commands and resubmit them.)
jsb@dasys1.UUCP (Jim Baunbach) (12/02/87)
In article <911@mcgill-vision.UUCP> mouse@mcgill-vision.UUCP (der Mouse) writes: >In article <5715@j.cc.purdue.edu>, ksb@j.cc.purdue.edu (Kevin Braunsdorf) writes: >> Can anyone suggest a solution to the novice user's classic error message: >> >> % rm * .o >> rm: .o nonexistent > >Sure, use rm -f, that way it won't complain :-) :-) > My problem is that I wanted to remove all my files but instead of typing "rm", by mistake I typed "rn" and was forced to read hundreds of postings on the pronunciation of "char", jokes about Oprah Winfrey, and requests of how to unROT13. Surely we must be prevented from allowing this to happen? -jsb -- Jim Baumbach {uunet}!mstan\ Big Electric Cat Public Unix {bellcore,cmcl2}!cucard!dasys1!jsb New York, NY, USA {sun}!hoptoad/ or uunet!actnyc!fred!jsb