cdash@boulder.UUCP (11/25/87)
yesterday, i got bit by rm. I was remotely logged in to a system over a network and had created a bunch of temp files. to delete them, i naturally typed in "rm t*" only the %$*#&^#@ network managed to drop the "t" and you all know what happened then. It wasn't too bad because with the archiving we do it was only 2 hours to get them back. Of course yeaterday's changes got lost and had to be redone. The point is that there are two things a command interface could do: 1) protect us from our own stupidity (i'm not convinced it should) 2) protect us from "extended system" errors like dropping a character but i'm not sure how you separate the two. -- cdash aka cdash@boulder.colorado.edu aka ...hao!boulder!cdash aka ...nbires!boulder!cdash aka (303) 593-3492
koreth@ssyx.ucsc.edu (Steven Grimm) (11/25/87)
In article <1257@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes: >yesterday, i got bit by rm. I was remotely logged in to a system over a network >and had created a bunch of temp files. to delete them, i naturally typed in >"rm t*" only the %$*#&^#@ network managed to drop the "t" and you all know what >happened then. It wasn't too bad because with the archiving we do it was only 2 >hours to get them back. Of course yeaterday's changes got lost and had to be >redone. The point is that there are two things a command interface could do: > 1) protect us from our own stupidity (i'm not convinced it should) > 2) protect us from "extended system" errors like dropping a character >but i'm not sure how you separate the two. >-- > >cdash aka cdash@boulder.colorado.edu aka ...hao!boulder!cdash > aka ...nbires!boulder!cdash aka (303) 593-3492 Sounds like you need better error detection on your network software more than a better "rm". If the problem is common, try using rm -i, which will prompt you for each filename. +New! Improved! Now 100% Artificial-+-+-----------------------------------+ |# # @@@ **** &&&&& $$$$$ % %| |Steven Grimm | |# # @ @ * * & $ % %+-+ ARPA: koreth@ucscb.ucsc.edu | |### @ @ **** &&&& $ %%%%%| | UUCP: ...!ucbvax!ucscc!ssyx!koreth| |# # @ @ * * & $ % %+-+ ______________________________| |# # @@@ * ** &&&&& $ % %| | |"Let's see what's out there."| +-----with NutraSour(TM)! No natural colors or preservatives!------------+
gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/26/87)
In article <1257@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes: >... "rm t*" only the %$*#&^#@ network managed to drop the "t" ... Some "network" that must be, to lose data at the user interaction level!
paul@tut.UUCP (11/29/87)
In article <6738@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: < In article <1257@boulder.Colorado.EDU> cdash@boulder.Colorado.EDU (Charles Shub) writes: < >... "rm t*" only the %$*#&^#@ network managed to drop the "t" ... < < Some "network" that must be, to lose data at the user interaction level! I can think of a very common "network" that does just that: rs232. Error checking? Why would we want that? 8-) At OSU, we have a laser printer that talks only rs232, no error detection. It will drop bits and bytes quite regularly. Some types of workstation keyboards talk to the host using rs232 also. Then there is the phone problem: this sort of thing happens quite often to me when using my 1200 baud modem. My personal opinion is that if someone relies on async without any error checking (or just parity), they are asking for trouble... I do not mean to imply that Mr. Shub is not accurately describing the situation, just pointing to a possible cause. Actally, this sort of thing has had me thinking about adding a shell builtin called "rm", which checks all of it's (un expanded) arguments to see if any are "*", asks for confirmation if they are, then does the ususal path search (sorta like (ack, bletch, phooy) MessyDos). -- Paul
allan@didsgn.UUCP (allan) (11/30/87)
In article <1257@boulder.Colorado.EDU>, cdash@boulder.Colorado.EDU (Charles Shub) writes: > yesterday, i got bit by rm. I was remotely logged in to a system over a network > and had created a bunch of temp files. to delete them, i naturally typed in > "rm t*" only the %$*#&^#@ network managed to drop the "t" and you all know what > happened then. ... > The point is that there are two things a command interface could do: > 1) protect us from our own stupidity (i'm not convinced it should) > 2) protect us from "extended system" errors like dropping a character > but i'm not sure how you separate the two. Isn't this a classic reliability problem for the network? Your "extended system" problem is really a faulty network problem. If your network (what type is it?) had supported reliable transfers, it would have detected the lost "t". Allan G. Schrum ..!gatech!rebel!didsgn!allan