cpcahil@virtech.uucp (Conor P. Cahill) (09/29/90)
In article <1990Sep29.043909.2577@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes: >In article <853@agcsun.UUCP> jackm@agcsun.UUCP () writes: >>I don't like aliasing rm to a shell that copies things to a ".deleted" >>directory, so don't tell me about those. > >Me neither. I also don't like aliasing rm to "rm -i". From your posts, it sound like you guys want to go back to the old V6 and possibly PWB shell days where an rm with a "match" character (either * or ?) would result in a [glob confirm] msg. For example: % ls Makefile test test.c test.o % rm * .o Makefile test test.c test.o .o [glob confirm] And you would have to type a y to really remove the files. This would protect you from the problem. When we upgraded to a System III machine, our users had all kinds of problems when this "feature" went away. -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
cbp@icc.com (Chris Preston) (09/30/90)
In article <853@agcsun.UUCP> jackm@agcsun.UUCP () writes: >I happened on an interesting way to protect against those accidental "rm *"'s > >To expand on this a bit, you could > > alias mkdir '/bin/mkdir \!^; touch \!^/#; chmod 0 \!^/#' > >So - anyone seen this before? See any drawbacks? > >-- >"How am I typing? Call 1-303-279-1300" Jack C. Morrison >Ampex Video Systems 581 Conference Place, Golden CO 80401 How about touch -- -NO-WAY! giving the result: rm: illegal option -- N rm: illegal option -- O rm: illegal option -- - rm: illegal option -- W rm: illegal option -- A rm: illegal option -- Y rm: illegal option -- ! usage: rm [-fir] file ... cbp --- Exclaimer: How about those Reds! Miracles abound. And they program too!
chetal@pyrps5.Pyramid.COM (Pradeep Chetal) (10/01/90)
I think there is a new program called "delete" from Project Athena at MIT.
I am not sure, so someone else on the net could elaborate on that.
/Pradeep
------------------------------------------------------------------------------
Pradeep Chetal UUCP: ...!{decwrl,sun,uunet}!pyramid!chetal
M/S 24 Internet: chetal@pyramid.com
Pyramid Technology Phone: (415) 335-8227 (O)
1295 Charleston Road
Mountain View, CA 94040raymond@math.berkeley.edu (Raymond Chen) (10/01/90)
I agree with Mr. Davidsen. Don't alias a system command. Write your own "safe rm", call it "can" or "del" or "era", then put the following in your private bin directory under the name "rm": #!/bin/sh echo "Don't use rm. Use del. If you really want rm, use /bin/rm" Too often, I've seen people who have a private little rm alias, who start relying on the -i option, then one day, they do a shell escape !rm * hoping to get the automatic "-i" option, and (oops!) the alias wasn't active (because they put it in their .login, not their .cshrc), or the application uses /bin/sh to handle shell escapes, or... (Heck, it happened to a friend of mine just last week...)
bill@bilver.UUCP (Bill Vermillion) (10/01/90)
In article <1986@sixhub.UUCP> davidsen@sixhub.UUCP (bill davidsen) writes: > You can stop after saying "I don't like aliasing rm" as far as I'm >concerned. I create a file called "-i" which comes first in those >firectories where I think I might make this mistake often. That force >interractive mode, and I can break if I didn't mean it. Sounds like a neat idea. So I built a directory I could trash and tried it. Now however, I can't seem to figure how to get rid of the -i. I have tried all variations of quotes, backslashes, wildcards. I know it's something simple, but I just can't seem to think of what it would be this time. -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
jik@athena.mit.edu (Jonathan I. Kamens) (10/02/90)
In article <128855@pyramid.pyramid.com>, chetal@pyrps5.Pyramid.COM (Pradeep Chetal) writes: |> I think there is a new program called "delete" from Project Athena at MIT. |> I am not sure, so someone else on the net could elaborate on that. I've been waiting to see if someone else mentioned it, so I wouldn't have to :-). The best way (in my opinion) to prevent problems with accidentally deleting files under Unix is to create a utility that deletes files in a way that allows them to be recovered, and then to use that utility instead of rm, and to teach your users to use that utility instead of rm. The "delete" package (which I wrote) is currently in use at Project Athena, and is (once again, in my opinion :-) worth looking into for those system administrators or Unix users for whom this is a problem. It's available in the comp.sources.unix archives as "undel2" (I forget which volume, but it's relatively recent). You also need the "et" library from the same volume in the c.s.u archives. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
gdtltr@freezer.it.udel.edu (Gary Duzan) (10/02/90)
In article <1034@bilver.UUCP> bill@bilver.UUCP (Bill Vermillion) writes: => =>Now however, I can't seem to figure how to get rid of the -i. I have tried =>all variations of quotes, backslashes, wildcards. => =>I know it's something simple, but I just can't seem to think of what it =>would be this time. => Many (if not all) rm's will allow "rm - -i". The extra "-" just says there are no more arguments. Of course, "rm ./-i" should work just about as well. Gary Duzan Time Lord Third Regeneration -- gdtltr@freezer.it.udel.edu _o_ -------------------------- _o_ [|o o|] An isolated computer is a terribly lonely thing. [|o o|] |_O_| "Don't listen to me; I never do." -- Doctor Who |_O_|
jik@athena.mit.edu (Jonathan I. Kamens) (10/02/90)
In article <1034@bilver.UUCP>, bill@bilver.UUCP (Bill Vermillion) writes: |> Now however, I can't seem to figure how to get rid of the -i. I have tried |> all variations of quotes, backslashes, wildcards. Read the monthly Frequently Asked Questions posting in comp.unix.questions. The last version was posted on September 6. The FIRST QUESTION answered by that posting is, "How do I remove a file whose name begins with a `-' ?" Here's the answer it provides: 1) How do I remove a file whose name begins with a "-" ? Figure out some way to name the file so that it doesn't begin with a dash. The simplest answer is to use rm ./-filename (assuming "-filename" is in the current directory, of course.) This method of avoiding the interpretation of the "-" works with other commands too. Many commands, particularly those that have been written to use the "getopt(3)" argument parsing routine, accept a "--" argument which means "this is the last option, anything after this is not an option", so your version of rm might handle "rm -- -filename". Some versions of rm that don't use getopt() treat a single "-" in the same way, so you can also try "rm - -filename". Also, the man page for "rm" usually mentions the "--" or "-" option. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8495 Home: 617-782-0710
datri@convex.com (Anthony A. Datri) (10/02/90)
>I don't like aliasing rm to a shell that copies things to a ".deleted" >directory, so don't tell me about those. Tcsh has a configuration option to verify rm * commands. --
cpcahil@virtech.uucp (Conor P. Cahill) (10/02/90)
In article <1034@bilver.UUCP> bill@bilver.UUCP (Bill Vermillion) writes: > >Now however, I can't seem to figure how to get rid of the -i. I have tried >all variations of quotes, backslashes, wildcards. 1. Read the FAQ posting to comp.unix.questins 2. try "rm ./-i" -- Conor P. Cahill (703)430-9247 Virtual Technologies, Inc., uunet!virtech!cpcahil 46030 Manekin Plaza, Suite 160 Sterling, VA 22170
mday@iconsys.uucp (Matt Day) (10/02/90)
The latest version of the Tcsh does a little check on every command you enter for "rm *" and prompts you with "Do you really want to delete all files? " accordingly. You don't have to alias anything, and it's not the least bit annoying. Tcsh can be FTP'ed from tesla.ee.cornell.edu (128.84.253.11) in /pub/tcsh-5.19/.... Even if you don't have problems with "rm *", I strongly recommend using this powerful shell. -- - Matthew T. Day, Sanyo/Icon, mday@iconsys.icon.com || uunet!iconsys!mday
brister@decwrl.dec.com (James Brister) (10/03/90)
I'm not sure I like it, but tcsh v5.18 has a feature where if you type `rm
*' it will ask for confirmation. This feature needs to be added at compile
time.
James
--
James Brister brister@decwrl.dec.com
DEC Western Software Lab., Palo Alto, CA {uunet,sun,pyramid}!decwrl!bristerasylvain@felix.UUCP (Alvin E. Sylvain) (10/04/90)
In article <853@agcsun.UUCP> jackm@agcsun.UUCP () writes: >I happened on an interesting way to protect against those accidental "rm *"'s >that take years off your life. [...] >This most likely isn't new, but I've never seen it. Anyway, just create >a file called "#" and turn off its write permission. Then if you type >"rm *", rm will ask if you want to override protection on "#" - BEFORE [...] > alias mkdir '/bin/mkdir \!^; touch \!^/#; chmod 0 \!^/#' [...] >So - anyone seen this before? See any drawbacks? [...] No, I haven't seen it before (cute!) ... one very minor drawback is that any files beginning with an even lower ascii value, such as space, ", !, or any control character, will be removed before you get to your # file. These files were probably created in error by a program, but may still be valuable. If this proves to be a problem (unlikely), you could solve it by using control-A instead of #. I don't see how a file could possibly begin with a NUL on a non-corrupted file system, so that one's out. Call it '?rm-check' or such, (?==^A) in case your ls command won't display control characters. (Ultrix displays them as ?) -- =======================Standard Disclaimers Apply======================= "We're sorry, but the reality you have dialed is no | Alvin longer in service. Please check the value of pi, | "the Chipmunk" or pray to your local diety for assistance." | Sylvain
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (10/08/90)
This discussion went by once before... the "#" file trick with funny
permissions doesn't work as well as creating a files called -i (touch
./-i). The reason is that even if you type "rm -f *", which bypasses the
asking on the readonly file, the filename -i at the start will force
interractive mode, you can look at the prompt and test your favorite
expletive, then abort. If you ever really want to blow everything away
you can "rm -f ./*".
--
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
sysop *IX BBS and Public Access UNIX
moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -mecarlj@hpcvmcdj.cv.hp.com (Carl Johnson) (10/08/90)
In comp.unix.misc, davidsen@sixhub.UUCP (Wm E. Davidsen Jr) writes:
This discussion went by once before... the "#" file trick with funny
permissions doesn't work as well as creating a files called -i (touch
./-i). The reason is that even if you type "rm -f *", which bypasses the
asking on the readonly file, the filename -i at the start will force
interractive mode, you can look at the prompt and test your favorite
expletive, then abort. If you ever really want to blow everything away
you can "rm -f ./*".
--
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
sysop *IX BBS and Public Access UNIX
moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me
This doesn't work on all systems either (does anything?). I just created
a directory then created a couple files plus a '-i' file. When I did a
'rm -f' there was no questions about deleting files, and an ls showed
only '-i' left. An 'rm -f' also deletes any file named '#' even if it doesn't
have write permissions. I am using HP/UX which is mostly Sytem 5 externally.
Carl Johnson carlj@hpcvmcdj.cv.hp.comjackm@agcsun.UUCP (Jack Morrison) (10/08/90)
I seem to have stirred up a little action here with the idea of having a non-writable file "#" in each directory to catch an accidental "rm *". This gets down to personal preference, but: * I don't think falling into the habit of "rm -f" would be a problem, since I rarely *want* to say "rm *". In fact, if I'm deleting everything, I'm probably deleting the directory too, in which case I'll be up one level typing "rm -rf dirname". * I don't object to aliasing rm, just to creating a mess on the disk for the 99.9% of the time I typed what I *meant* to type. On the other hand, I don't want to alias rm to "rm -i", because it's only "rm *" that's likely to be a mistake. * I *do* have a "del" script that lists all the files I've asked to delete, and asks for one confirmation. (It's included below). I tend to use this when I want to delete a bunch of files, but want to be sure what the wild carding is going to get me. In otherwords, instead of ls <expr> and then rm <expr>. I also explicitly use "rm -i" when I *know* the wildcard is going to hit some things I don't want deleted. * My favorite reply was the idea of creating a file "-i". Pretty sneaky. One disadvantage is that if I really did mean "rm *", it's going to ask me about *everything*, instead of a single query to make sure. I suppose other commands might get confused seeing a "-i" too. (And some users seemed to be confused about how to remove the "-i" file). * Eirik Fuller suggests a subdirectory with links back to the files I don't want to delete by accident. I find that a bit too much work, and worry about keeping the subdirectory up to date as new files are created. * Jay Plett points out that some systems automatically delete files with names beginning in "#" periodically. If this is the case, another pre-alphabetic name could be used instead. I'd guess that the automatic purger would leave read-only files alone anyway, but it might not. * Frank Peters (and others) point out that tcsh, among other benefits, has a variable you can set that will ask for confirmation if you say 'rm *'. My conclusion (so far) is that the non-writable "#" is an innocent way to do what I want when using csh. Oh, here's my "del" shell script (with no guarantees): ===================================================================== : delete files with confirmation if test $# -eq 0 then echo usage: del file ... else if test $# -eq 1 then echo -n delete $* '(y)?' 1>&2 else ls $* echo -n 'delete these files (y)?' 1>&2 fi read answer if test x$answer = xn -o x$answer = xno then echo no 1>&2 else echo yes 1>&2 rm $* fi fi ===================================================================== -- "How am I typing? Call 1-303-279-1300" Jack C. Morrison Ampex Video Systems 581 Conference Place, Golden CO 80401
andyo@glasperl.masscomp (Andy Oram) (10/09/90)
I didn't want to jump in and be a wet blanket, because this thread turned up
some neat tricks, but I don't think nobody has mentioned this yet -- really, a
rogue rm command is the least of your worries. I myself am much more likely
to wipe out my work by:
Moving a file to a directory that already has a file with the same
name (yes, I know that mv and cp have -i too, but you can spend your
life disabling utilities' standard practices).
Writing out a file that I've munged, or where I accidentally deleted
90% without realizing it, because the part that showed up on my screen
looked fine.
Getting "make" confused and having it think your source is a target,
and removing it because an error occurred.
etc., etc.
So let me act like a school-marm for just a moment, and say that the minimal
protection you need is the classic protection: daily back-ups and source
control. The most state-of-the-art solution I know of would be version
control, like Emacs implements for edited files, and like a certain operating
system I dare not mention without being laughed at implements across the whole
system.
-------------------------------------------------------------------------------
Andrew Oram Concurrent Computer Corporation
(I don't represent Concurrent; this message represents my own opinion)
Digital Communications Route: andyo@westford.ccur.com
{harvard,uunet,petsd}!masscomp!andyo
Analog Communications Route: (508) 392-2865
Automatic UN*X documentation utility:
cref | compress | crypt | man
-------------------------------------------------------------------------------aas@boeygen.nr.no (Gisle Aas) (10/11/90)
The "-i" file trick does not work if you use rm the right way: rm -f - * -- Gisle Aas | snail: Boks 114 Blindern, N-0314 Oslo, Norway Norsk Regnesentral | X.400: G=Gisle;S=Aas;O=nr;P=uninett;C=no voice: +47-2-453561 | inet: Gisle.Aas@nr.no
gwoho@nntp-server.caltech.edu (g liu) (10/12/90)
a good way to protect people from accidental "rm *" is to type "rm /bin/rm"
bill@bilver.UUCP (Bill Vermillion) (10/12/90)
In article <1990Oct11.184004.9353@nntp-server.caltech.edu> gwoho@nntp-server.caltech.edu (g liu) writes: > >a good way to protect people from accidental "rm *" is to type "rm /bin/rm" Well you can't do that on SysV type systems. You will get an error message with "Text file busy". It won't removed itself, because it is in use, trying to remove itself ;-) -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/12/90)
In article <AAS.90Oct11100737@boeygen.nr.no> aas@boeygen.nr.no (Gisle Aas) writes: >The "-i" file trick does not work if you use rm the right way: rm -f - * I believe that the goal is to protect from mistyping "rm file1 n*" and getting "rm file1n *". It has happened to me when in a hurry. Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif
pf@artcom0.north.de (Peter Funk) (10/14/90)
In <1100@bilver.UUCP> bill@bilver.UUCP (Bill Vermillion) writes: bv> In article <1990Oct11.184004.9353@nntp-server.caltech.edu> gwoho@nntp-server.caltech.edu (g liu) writes: bv> > bv> >a good way to protect people from accidental "rm *" is to type "rm /bin/rm" bv> Well you can't do that on SysV type systems. You will get an error message bv> with "Text file busy". It won't removed itself, because it is in use, bv> trying to remove itself ;-) On SysV there is another good way yielding similar results for the same kind of lusers: mv /bin/rm '/bin/rm -i' ;-) Sorry .... I couldn't resist... ;-) ;-) --- Peter Funk \\ ArtCom GmbH, Schwachhauser Heerstr. 78, D-2800 Bremen 1 Work at home: Oldenburger Str.86, D-2875 Ganderkesee 1 /+49 4222 6018 (8am-6pm) >> PLEASE Don't send me BIG mails (oversea) ! I've to pay for it : $0.3/kB Don't use the bang path of this news article for mails (They will bounce). Only the address 'pf@artcom0.north.de' will work. Thank You ! <<
guy@auspex.auspex.com (Guy Harris) (10/17/90)
>Well you can't do that on SysV type systems. You will get an error message >with "Text file busy". With any luck, that botch is fixed in S5R4.
ag@cbmvax.commodore.com (Keith Gabryelski) (10/17/90)
In article <4195@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>Well you can't do that on SysV type systems. You will get an error message >>with "Text file busy". > >With any luck, that botch is fixed in S5R4. It is. Pax, Keith
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) (10/17/90)
In article <4195@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>Well you can't do that on SysV type systems. You will get an error message >>with "Text file busy". >With any luck, that botch is fixed in S5R4. OK...I give up. Why is not being able to remove a program in use a botch? -- Jay Maynard, EMT-P, K5ZC, PP-ASEL | Never ascribe to malice that which can jmaynard@thesis1.hsch.utexas.edu | adequately be explained by stupidity. "It's a hardware bug!" "It's a +--------------------------------------- software bug!" "It's two...two...two bugs in one!" - _Engineer's Rap_
jik@athena.mit.edu (Jonathan I. Kamens) (10/17/90)
In article <4198@lib.tmc.edu>, jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: |> OK...I give up. Why is not being able to remove a program in use a botch? When you delete a file that a process has open, the file is removed from the filesystem, but the process which has it opened it continues to have access to it until the file is closed (unless it's on a non-local filesystem such as NFS, in which case things may get a bit more complicated :-). If multiple processes have the file open, they all continue to be able to use it until they all close it. The kernel removes the file from its directory, but doesn't actually completely remove the file until there are no longer any processes that have opened it. Binaries should be treated the same way. There is no reason not to be able to delete a file which is an executable image currently in use. There *are* reasons why you *should* be able to do so. For example, if I want to install a new version of a program without disturbing people using the old version, the best way to do it is to delete the old version and then copy the new one into place. This way, people who are using the executable continue to get use that executable when the kernel tries to swap in from it, but people who run the program from that point on will get the new version. If I can't delete a running executable, I am left with two choices: (a) move the file to a different name (e.g. "foo.old") and copy the new one into place, or (b) copy the new binary on top of the old one. The former choice is less than optimal because I have to remember to go back and delete the ".old" file later (and who knows, somebody may keep it running it all night, or for several days, or whatever!), and the second choice is less than optimal because after the new binary is copied on top of the old one, people will get swap errors when the kernel tries to swap in from the (nonexistent) old executable image. -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710
rmtodd@servalan.uucp (Richard Todd) (10/17/90)
jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: >>With any luck, that botch is fixed in S5R4. >OK...I give up. Why is not being able to remove a program in use a botch? I can remove a link to an file that some process has opened with the open() (or creat()) syscall; the file blocks and its inode continue to remain on the disk unharmed even after the last link is removed. Yet I can't remove a link to an inode that just happens to include an executing progam. Why should these two cases be any different? -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp "Cancelling a posted message means posting a cancel message."-Maarten Litmaath
jmm@eci386.uucp (John Macdonald) (10/18/90)
In article <1990Oct16.215634.23052@athena.mit.edu> jik@athena.mit.edu (Jonathan I. Kamens) writes: |In article <4198@lib.tmc.edu>, jmaynard@thesis1.hsch.utexas.edu (Jay Maynard) writes: ||> OK...I give up. Why is not being able to remove a program in use a botch? | | [... description of why ...] There is no reason not to be able |to delete a file which is an executable image currently in use. There *are* |reasons why you *should* be able to do so. [...] | | If I can't delete a running executable, I am left with two choices: (a) move |the file to a different name (e.g. "foo.old") and copy the new one into place, |or (b) copy the new binary on top of the old one. The former choice is less |than optimal because I have to remember to go back and delete the ".old" file |later (and who knows, somebody may keep it running it all night, or for |several days, or whatever!), and the second choice is less than optimal |because after the new binary is copied on top of the old one, people will get |swap errors when the kernel tries to swap in from the (nonexistent) old |executable image. If this is a frequently occurring activity, then there is a simple way of getting choice (a) to work correctly. Make a directory "old" in each bin directory. To destructively update foo, "mv foo old/rm$$", and then copy in the new version. Have a cron job that runs nightly that does "find /bin/old /usr/bin/old <any others> -type f -print | xargs rm -f". It will keep trying until it can actually do the job. In times of heavy program upgrades, the cron job could be tried hourly if the old versions are cluttering up the disk. Alternately, the script that does moves old stuff to the old directory could get fancy - remove if possible before moving to old, and try to clean out the old directory too in case something is now removable. -- Cure the common code... | John Macdonald ...Ban Basic - Christine Linge | jmm@eci386
jik@athena.mit.edu (Jonathan I. Kamens) (10/19/90)
In article <1990Oct18.152958.15635@eci386.uucp>, jmm@eci386.uucp (John Macdonald) writes: |> If this is a frequently occurring activity, then there is a simple way of |> getting choice (a) to work correctly. Make a directory "old" in each bin |> directory. To destructively update foo, "mv foo old/rm$$", and then copy |> in the new version. Have a cron job that runs nightly that does |> "find /bin/old /usr/bin/old <any others> -type f -print | xargs rm -f". |> It will keep trying until it can actually do the job. In times of heavy |> program upgrades, the cron job could be tried hourly if the old versions |> are cluttering up the disk. Alternately, the script that does moves old |> stuff to the old directory could get fancy - remove if possible before |> moving to old, and try to clean out the old directory too in case something |> is now removable. So, if we don't want "old" directories all over the place, then every partition on the system has to know have an old directory somewhere on it (so the "mv" can occur without copying across partitions), and every makefile that does installations has to know what directory it's supposed to move the old binary into when installing. The makefiles can be simpler if every directory has an old subdirectory, but that means that there are "old" directories scattered all over the system cluttering it up. Alternatively, we could just fix the System V kernel so it does the right thing and allows you to unlink the executable. Why are you fighting so hard to figure out obviously suboptimal solutions, when the correct solution is already clear (and is trivial to implement, and in fact is already implemented in SVR4 and in most (if not all) BSD-based systems)? -- Jonathan Kamens USnail: MIT Project Athena 11 Ashford Terrace jik@Athena.MIT.EDU Allston, MA 02134 Office: 617-253-8085 Home: 617-782-0710