drascic@ecf.UUCP (10/02/87)
I'm posting this for a friend who does not have USENET access. Please e-mail replies to me, and I will forward them to him. (or post them, if you want....) POSTING FOLLOWS: Hello. I have recently found myself in the position of having to present a lecture on Human Factors in Human Computer Interface design to a large number of programmers, most of whom have never heard of Human Factors. In an effort to avoid being dry and boring I would like to have a fair repetoire of anecdotes to entertain and illustate the general principals I will be discussing. Unfortunately I know very few. (most of my reading is journal articles --- good, but pretty dry). So I'm asking you folks for amusing and/or interesting stories dealing with Human Factors design. They can be apocryphal, or personal experience, just please indicate which. I'll even give you credit for them if you really want it. -john schrag END OF POSTING That's it. You can try mailing me at drascic@ecf.toronto.edu, or just use the reply.... the mailer daemon gets grumpy sometimes,though. -dd
avr@hou2d.UUCP (Adam V. Reed) (10/04/87)
In article <301@mv03.ecf.toronto.edu>, drascic@ecf.toronto.edu (jkins) writes: > So I'm asking you folks for amusing and/or interesting stories dealing with > Human Factors design. They can be apocryphal, or personal experience, > just please indicate which. I'll even give you credit for them if you > really want it. > -john schrag This is personal experience: About 10 years ago, I was teaching AI to a class of doctoral candidates in psychology. Because of the limitations of the machine we were using, our LISP environment had very terse error messages and no error recovery to speak of - it often crashed when a reserved word was used in the wrong context. One day, the brightest student in the class wrote a rather elegant small program, and I told her to save it on a diskette. Her words: "I wrote 'SAVE TO DISKETTE A', just like you said. Then the computer said 'WRITE PROTECTED'. So I wrote 'PROTECTED', and the system crashed." Adam Reed Bell Labs hou2d!avr
robert@cantuar.UUCP (10/11/87)
jkins (drascic@ecf.toronto.edu) writes: >I'm posting this for a friend who does not have USENET access. Please... >Hello. I have recently found myself in the position of having to present >a lecture on Human Factors in Human Computer Interface design to a large... Ok, this gives me an excuse... We use both Unix and Primos a lot here, and students learn Primos before learning Unix. A pair of students were working on a first big Unix programming project, and had a habit of backing up their files by keeping "backup" directories in the source directories. So they'd often say: cp precious backup/precious But they were very used to Primos, and in Primos the directory mark is not "/" but ">". So one time they said: cp precious backup>precious !!! And they were very puzzled about what happened. At first they didn't see what was wrong with the line, but eventually saw the ">". They then realized that standard output was re-directed to their file, and because "cp" has no standard output, "precious" was now null. No problem, it had just made a backup. That was then they learned that the shell truncates and opens files for redirection *before* it arranges for the relevant programme to be executed. So they had lost the file, and not made a backup. But there was the *last* backup, yes? That was when they learned that "cp" takes a directory name in the last position as meaning the same name is meant to be used in the directory. So with a perfectly good looking backup command, they had not only not made a backup, but had lost the file itself, and destroyed the last backup. To end the story happily: After much angst, they realised that it was a Yacc file with a grammar and some large C functions. The grammar hadn't changed since the last tape backup a fortnight before, and the C functions could be captured back from the last C file Yacc had generated. It's interesting to note that even in Primos the statement wouldn't have been correct (even substituting "copy" for "cp"), because in Primos the current directory must be indicated as "*", so the second file should have been "*>backup>precious". Of course, "*" would yield more problems in Unix! None of this is new, of course, and similar problems occur when a new natural language is learned. -- Internet(ish): robert@cantuar.{uucp,nz} Spearnet/Janet: r.biddle@nz.ac.canty UUCP: ...!{watmath,munnari,mcvax,...!uunet!vuwcomp}!cantuar!robert NZ Telecom: Office: +64 3 482 009 x8352 Home: +64 3 64741; +64 21 76205 NZ Post: University of Canterbury, Christchurch, Aotearoa / New Zealand
rwhite@nusdhub.UUCP (Robert C. White Jr.) (10/14/87)
My ongoing UNIX vs. MS-DOS anticdote. To some extent MS-DOS is a back-hack of UNIX syntax, at least as far as command line syntax. [I am talking borne shell here]. I work and deal with "just barley ms-dos users" every day. These people ALWAYS type things like "cd\break". In ms-dos, any "internal" commands dealing with pathnames are first-space-optional. that is, "cd\break" and "cd \break" are functionally identical. To my misery I have been given a group of such people, which I am to educate in the basics of UNIX. No matter how many times I say "ALWAYS USE A SPACE" these people don't and I end up with 'What does "cd/break: not found" mean?' The moral: Just because it is an option, dosn't mean it's an option worth using. As an after-note, some versions of ms-dos have started to complain about this usage also.... That'll teach em. Rob.
al@gtx.com (0732) (10/20/87)
How about the person who types
rm * .o
instead of
rm *.o
The sinking feeling starts when you get the message ".o not found"
----------------------------------------------------------------------
| Alan Filipski, GTX Corp, 2501 W. Dunlap, Phoenix, Arizona 85021, USA |
| {ihnp4,cbosgd,decvax,hplabs,seismo}!sun!sunburn!gtx!al (602)870-1696 |
----------------------------------------------------------------------reese@eeg.UUCP (Reese E. Faucette) (10/22/87)
In article <447@gtx.com>, al@gtx.com (0732) writes: > How about the person who types > rm * .o just create a file called "-i" in your directory that you want protected! then "rm *" expands to "rm -i file1 file2 file3 ..." (unless you have other files beginning with weird characters) -r -- Reese E. Faucette, EEG Systems Laboratory 1855 Folsom St, San Francisco, Ca 94103 (415) 621-8343 {ihnp4,lll-crg,dual,qantel,pyramid}!ptsfa!eeg!reese
geoff@desint.UUCP (Geoff Kuenning) (10/24/87)
> just create a file called "-i" in your directory that you want protected! > then "rm *" expands to "rm -i file1 file2 file3 ..." > (unless you have other files beginning with weird characters) What a typically Unix solution. Even to the flaws: you have to put up with an ugly file in your directory, and it doesn't work if you type "rm test *". -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
ocker@yale-zoo-suned..arpa (John Ockerbloom) (10/27/87)
Da
caf@omen.UUCP (Chuck Forsberg WA7KGX) (10/27/87)
In article <1325@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes:
:> just create a file called "-i" in your directory that you want protected!
:> then "rm *" expands to "rm -i file1 file2 file3 ..."
:> (unless you have other files beginning with weird characters)
:
:What a typically Unix solution. Even to the flaws: you have to put up
:with an ugly file in your directory, and it doesn't work if you
:type "rm test *".
One other flaw that can be circumvented: it takes up an inode.
So, my "-i" has many links to it, it only takes up a directory slot
plus one inode total.pattis@uw-june.UUCP (Richard Pattis) (10/27/87)
In 1982 I was using the UCSD P-system editor. After deciding to leave the editing environment, the user is asked to press a key to inform the machine what to do with the resulting file. W means write it out; E means exit without saving - these keys are adjacent. In 6 months of intensive work on this system I screwed up only once, after editing a few hours of text. Rich Pattis
hunt@spar.SPAR.SLB.COM (Neil Hunt) (10/28/87)
In article <1325@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: > just create a file called "-i" in your directory that you want protected! > then "rm *" expands to "rm -i file1 file2 file3 ..." > (unless you have other files beginning with weird characters) What about when you have a file called '-a' in your directory as well ! Seems to me that appropriate use of write protections is a better solution. Failing that, how about an alias % alias rm 'rm -i' Neil/.
eugene@pioneer.arpa (Eugene Miya N.) (10/28/87)
Years ago, when I was first learning computers (on what was called the
Culler-Fried System), I make a mistake on a password and hit an "0"
for an "O". Correcting this mistake is another interesting security story.
In the last two years, I've noticed an increasing tendency for people to
mistake: "0" and "O", "1" (one), "l" (ell), and "I" (eye): both
secretaries on word processors and managers new to computers. The "l"
for a "1" is especially annoying.
Also don't forget the Therac 25 Radiation tradement machine: or
VT-100 (Up arrow key) Considered Lethal. Some references in RISKS,
a 20/20 Segment (you can get a transcript), and a DATAMATION article.
From the Rock of Ages Home for Retired Hackers:
--eugene miya, NASA Ames Research Center, eugene@ames-aurora.ARPA
"You trust the `reply' command with all those different mailers out there?"
"Send mail, avoid follow-ups. If enough, I'll summarize."
{hplabs,hao,ihnp4,decwrl,allegra,tektronix}!ames!aurora!eugenesher@sunybcs.uucp (David Sher) (10/28/87)
I once speant several days searching some intense numeric code for a
bug. I finally found that the bug wasn't in the code at all but in
the driving shell script. A 1 had been replaced by an l and the
code used atof to parse its arguments so instead of reading
1.5 it read 0. I guess I should have used sscanf(argv[1],"%d",&foo);
and checked the return value but I was lazy, and boy did I pay for it.
Have I drifted from the topic?
-David Sher
-David Sher
ARPA: sher@cs.buffalo.edu BITNET: sher@sunybcs
UUCP: {rutgers,ames,boulder,decvax}!sunybcs!shergobbel@parcvax.Xerox.COM (Randy Gobbel) (10/29/87)
Bravo, the text editor that was most widely used around PARC several years ago, had a command-mode/insertion-mode user interface with undo of the last command. Commands were single alphabetic characters. The classic error in this editor was to type "ENDLOOP", a Mesa reserved word, when the editor wasn't in command mode. To Bravo, this meant "Everything [select entire buffer]" "Normalize [scroll to beginning of selection]" "Delete" "Look Open [add two more points of leading to the current paragraph]". The last command's only effect was to make it impossible to recover from the deletion of the entire buffer. -Randy ---- Randy Gobbel, Xerox PARC/ISL Disclaimer: Opinions here are mine, not my employer's Arpanet: gobbel.pa@xerox.com UUCP: ...!hplabs!parcvax!gobbel
rem@remsit.UUCP (10/29/87)
In article <3389@uw-june.UUCP> pattis@uw-june.UUCP (Richard Pattis) writes: >In 1982 I was using the UCSD P-system editor. After deciding to leave the >editing environment, the user is asked to press a key to inform the machine >what to do with the resulting file. W means write it out; E means exit >without saving - these keys are adjacent. In 6 months of intensive work >on this system I screwed up only once, after editing a few hours of text. After working with UCSD Pascal on the Apple for a long time, a friend of mine needed some help writing a program in Apple Pilot. When I first took a look at it, I noticed that it (the Pilot "system") was much like what I was used to (the disk was crunched now and then, etc.). In fact, the editor was the same Pascal editor I had been using, except for one subtle but important difference: ESC (abort insert) and CTRL-C (save insert) were switched. If I had a dime for every time I typed in a screenful of text, only to hit CTRL-C and have it magically disappear... -- Roger Murray UUCP: ...!{ihnp4,randvax,sdcrdcf,ucbvax}!ucla-cs!cepu!ucla-an!remsit!rem ARPA: cepu!ucla-an!remsit!rem@CS.UCLA.EDU [formerly LOCUS.UCLA.EDU]
geoff@desint.UUCP (10/30/87)
I worked on an early 8080 development system that initialized
the floppy on the command "I<CR>", and copied floppy 0 to floppy 1
on the command "C<CR>". Of course, there were several other
single-character commands, just to encourage you to screw up...
--
Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoffdaveb@geac.UUCP (10/30/87)
In article <3389@uw-june.UUCP> pattis@uw-june.UUCP (Richard Pattis) writes: >In 1982 I was using the UCSD P-system editor. [when leaving...] W means >write [the file] out; E means exit without saving - these keys are adjacent. Compare this with the more modern "rn" program, which uses "a" for abort and "s" for send... trivially mistypable. -- David Collier-Brown. {mnetor|yetti|utgpu}!geac!daveb Geac Computers International Inc., | Computer Science loses its 350 Steelcase Road,Markham, Ontario, | memory (if not its mind) CANADA, L3R 1B3 (416) 475-0525 x3279 | every 6 months.
dick@ccb.ucsf.edu.UUCP (11/02/87)
I remember giving other database systems Easytrieve points for obscure or misguided commands in our study of 18 possibilities for enhancing researchers access to their data. The original gaffe was "flush" to save all the data on disk. It made some sense if you were the programmer, but was reverse to the user. Take a look at back issues of comp.risks for more. One I do recall was about a purported memo requiring titles of papers to put the significant words among the first five. The administrator vigorously denied the allegation. Instead, he claimed that the bibliographic search just used the first five words. To me that was much worse, not to advise folks to do something, just hide their papers if they don't. One of my favorite papers would then be found only by "On the Criteria to be". Since the entire history of computing is so short, we have barely begun to discover what the human factors are. In particular, I am bothered daily by every system I use. In CMS, in full screen mode, using XEDIT, every <RETURN> that I type at the end of a line takes me to the command area. Not what I meant. Paging in the editor is PF-8 but in the shell (command mode) it is PA-2. Come on guys. Continuing with CMS, each command has its own rules for magic characters in file names. Logical partitioning of files into collections requires physical partitioning into mini-disks. The continuing cry from users for a little consistency has been heard, so now every presentation claims to attend to that detail, to the exclusion of a good or usable interface. In Unix, we have other problems. You obviously know about the little matter of difference between "rm *.o" and its disastrous relative "rm * .o". I have problems with other magic characters and would prefer that the system tell me which of the characters i just typed were magic at all. My favorite complaint about C is that if you ask if a = b then it does, now. In vi, there is NO indication of what mode you just entered, you have to know. Of course, we computer weenies use editors so much that their styles become matters for religious warfare. I once had a say on what to do to improve on the UCSD editor and my first choice was to give access to the file directory information from within the editing session. It helped, some. Three years ago, a computer system was introduced to the mass market which attended to the user interface issues. The Mac was a first year success and has improved since. It clearly stands head and shoulders above the competition. Still, the complex multi-key combinations that are used to invoke seldom used functions completely violate the fine principles in evidence elsewhere. Perhaps one menu choice should reveal a whole new menu bar instead, with ALL the obscure stuff listed there. Another Mac "feature" is that when you select a file to start the application that made it, and that application can't be found by whatever search strategy the finder uses, you get a single generic error dialog box which doesn't even hint about the four character creator code or give its value. System bombs are pretty obscure too. These guys and gals did a great job in a hundred ways, and it shows up in the 10 to 1 difference in time-to-productivity and the two or three to one difference in hours used per day. But still, it'll be many years till naive users will be well served by their computers; after all, for the most part, computers are continuing to be deaf, dumb, and blind. Dick Dick Karpinski Manager of Minicomputer Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski Domain: dick@cca.ucsf.edu Home (415) 658-6803 Ans 658-3797
dick@ccb.ucsf.edu (Dick Karpinski) (11/04/87)
One of the nicest things in the VS ASE editor derived from the UCSD Pascal editor was the trainable function keys. I wrote a regular column for a while about neat ways to use them. There was even one example of doing arithmetic with them (using table lookup). However, one feature was that the system date was automatically loaded into <F8>. This was handy for dating a letter or memo while inserting text, but if you hit that key by accident in command mode, there was one month when things would go quite awry. Any day in May would (if executed) ask to remargin (the Margin command) the current paragraph. The a would be ignored and the y would acceed to the proposed action. If you were in the midst of a program, this would effectively destroy everything forward and backward of the cursor up to a blank line. The compiler could handle the result just fine, but people were out of luck. Dick Dick Karpinski Manager of Minicomputer Services, UCSF Computer Center UUCP: ...!ucbvax!ucsfcgl!cca.ucsf!dick (415) 476-4529 (11-7) BITNET: dick@ucsfcca or dick@ucsfvm Compuserve: 70215,1277 USPS: U-76 UCSF, San Francisco, CA 94143-0704 Telemail: RKarpinski Domain: dick@cca.ucsf.edu Home (415) 658-6803 Ans 658-3797
djones@megatest.UUCP (Dave Jones) (11/06/87)
An old version of emacs we used to use created backup files tagged with ".BAK". One day I quickly typed "rm *.BAK", or so I thought. To my horror, I looked at the command line and saw, "% rm *>BAK". The greater-than is a capital period, and I depressed the shift key just a fraction of a second early. The system was industriously deleting all my files and piping the (empty) listing to a new file called BAK.
chip@ateng.UUCP (Chip Salzenberg) (11/11/87)
In article <1621@megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >An old version of emacs we used to use created backup files tagged with >".BAK". One day I quickly typed "rm *.BAK", or so I thought. To >my horror, I looked at the command line and saw, "% rm *>BAK". I had a similar disaster with an editor that creates backups of the form ",filename". I missed the comma and typed "rm *". I now use a (safe!) alias to do this deletion: alias b 'rm -f ,*' -- Chip Salzenberg "chip@ateng.UUCP" or "{codas,uunet}!ateng!chip" A T Engineering My employer's opinions are not mine, but these are. "Gentlemen, your work today has been outstanding. I intend to recommend you all for promotion -- in whatever fleet we end up serving." - JTK
norman@sdics.ucsd.EDU (Donald A. Norman) (11/12/87)
A common form of error results from incompatible standards. When one
system uses one technique and another system a different technique for
the same result, or the same technique for a different result, capture
error is likely, where the more frequently invoked procedure is
performed instead of the intended less-frequently performed one.
Examples:
======================================================================
VI text editor UCSD Pascal text editor
ESC => accept typed material ESC => abort -- destroy typed material
(with no recovery possible)
(the vi editor and UCSD pascal editors were frequently used by the same
people here at UCSD. The incompatibility is perhaps understandable
because vi didn't exist when UCSD pascal was developed, but the lack
of an undo on the UCSD Pascal system is not excusable). had there
been an undo, the noise level around here would have been considerably
less.
======================================================================
SUN window system Macintosh multifinder
Symbolics window system
To direct text to any window on the screen (i.e., to make that window
active)
place mouse cursor over window place mouse cursor on window and
CLICK
To move text into the internal buffer (clipboard) for a copy --paste
sequence
highlight desired region highlight desired region and type
command-c (or select "copy")
The lack of clicks on the sun, either to activate the window or to do
their equivalent of "copy" constrasts with the clicks required with
other systems leads to much eror and confusion when the two systems
are used by the same people. The errors are frequent (I use a
macintosh and sun next to one another, and this very minute I am using
my sun via my macintosh). Because both systems are pretty robust,
with powerful undos, the problems are usually not serious, unless you
accidentlaly move the mouse cursor to the emacs window on the sun and
type, in which case wild things can happen. There really ought to be
a more visible indication of which window is active and, in the case
of the copy command, of the fact that matrerial is in the clipboard or
copy buffer (the old Xerox Bravo editor used to display the contents
of the copy buffer at all times -- that really helped.)
======================================================================
Britain United states
light switches: up = off up = on
======================================================================
Britain, Japan, .. United states
auto drives on left auto drives on right
car in round-about (circle) car in roundabout (circle)
has right of way must yield to entering autos
(These are included to indicate that problems are not restricted to
computer design. Note that when one takes the ferry between the
continent and britain, the lack of compatibility makes for immediate
diffiuclties with surprisingly little warning or guidance on either
side.)
don norman
Donald A. Norman
Institute for Cognitive Science C-015
University of California, San Diego
La Jolla, California 92093
norman@nprdc.arpa {decvax,ucbvax,ihnp4}!sdcsvax!ics!norman
norman@sdics.ucsd.edu norman%sdics.ucsd.edu@RELAY.CS.NETalastair@geovision.UUCP (Alastair Mayer) (11/12/87)
Rich Pattis mentions an editor with the adjacent keys, 'W' and 'E' having
totally different meanings (write vs exit). I've got one a little
closer to home for Unix users. Take a look at where the 'X' and 'C'
keys are on the keyboard, and consider what those letters (as flags)
mean to 'tar(1)'. I only screwed it up once, on a 2.5 Meg disk
cartridge.... (sigh)
--
Alastair JW Mayer BIX: al
UUCP: ...!utzoo!dciem!nrcaer!cognos!geovision!alastair
"Anyone who is not shocked by quantum theory has not understood it."chris@mimsy.UUCP (Chris Torek) (11/13/87)
In article <1621@megatest.UUCP> djones@megatest.UUCP (Dave Jones) writes: >... One day I quickly typed "rm *.BAK", or so I thought. To >my horror, I looked at the command line and saw, "% rm *>BAK". ... >The system was industriously deleting all my files and piping the >(empty) listing to a new file called BAK. Which, by the way, was also removed by rm. The shells (csh, sh; I have not tried ksh) perform `<' and `>' redirection before `*' expansion. % cat * > together will often fill up a file system, since `*' might expand to `ch1 ch2 ch3 ch4 index together'. cat eventually starts copying from the beginning of `together', appending to its end, which provides more text for cat to read, which writes more, which provides more, which . . . . -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
chris@mimsy.UUCP (Chris Torek) (11/13/87)
In article <9332@mimsy.UUCP> I wrote >... The shells (csh, sh; I have not tried ksh) perform `<' and `>' >redirection before `*' expansion. Correction: only `csh' does this. > % cat * > together This is also a bad example, as `cat' explicitly checks each input file against cat's standard output, to prevent loops. Using something like `soelim' that does not have such checks will cause such a loop. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) (11/13/87)
This request has spawned many stories involving rm * (or
variants) that were not intentional. When we first started with
unix four people managed to destroy things within the same day
that way. In my case, I had worked all night to build a new and
wondrous piece of software. It all worked, etc. So I was doing
the final clean up: I typed rm *.c instead of rm *.o and the
whole project went down the drain!
Shortly thereafter we made a change to the shell: in the code
that did global expansions (*,?) we set a flag and if the command
name was "rm* or del*" we said confirm: and printed out the
expanded list of files.
Even with this aid we still had people screw up but not nearly as
often.
Then there was the time we did rm -rf ../*
The moral of this is that the command interpreters need to be
modified to request confirmation of potentially fatal things such
as rm * and it must be in the command interpreter as the command
itself can't know whether the list is an expanded list or a
individually entered list.
After that is fixed we can talk about Jim Gillogly's spelling
corrector shell.
--
=Dennis L. Mumaugh
Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlmdhb@rayssd.RAY.COM (David H. Brierley) (11/16/87)
If users removing all of their files by inadvertently typing "rm *" is
a habitual problem at your site, why not make the command default to
interactive mode? If you have source this is a trivial task and if you
don't have source it's not much harder. Simply move the real rm
command to some new secret place, for example: /bin/.hidden/rm, and
then make /bin/rm be a shell script which invokes the real rm with the
"-i" flag. If you wanted to be real fancy you could add a new option,
say "-I", which would disable interactive mode. Another possibility
would be to have the shell script enable interactive mode if you try to
remove more than some pre-determined number of files. That way you
could still type "rm foo" without having to use interactive mode but
"rm foo *" would put you into interactive.
Of course, nothing you can do will ever solve the problem completely
since even the most expert user will occasionally make mistakes. Just
the other day I wiped out a weeks worth of work by typing "cc -o pgm.c"
on my AT&T unix-pc. I had meant to use -O to invoke the optimizer.
Instead, it optimized away all of my code by giving me a message to the
effect of "no source file" and happily creating a zero length output
file called "pgm.c". I was not at all amused. I now have a shell
script in place of cc which checks all its arguments for consistency
(i.e. you can't say "-o pgm.c").
--
David H. Brierley
Raytheon Submarine Signal Division
1847 West Main Road
Portsmouth, RI 02871
Phone: (401)-847-8000 x4073
Internet: dhb@rayssd.ray.com
Uucp: {cbosgd, gatech, linus, mirror, necntc, uiucdcs} !rayssd!dhbandy@rocky.STANFORD.EDU (Andy Freeman) (11/17/87)
In article <1402@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: [We're talking about "rm *". Guess why I have a csh alias for rm that always asks about every file. When I'm absolutely sure that I want to delete a number of files and I don't want to answer questions, I pipe the whole command off to sh.] >The moral of this is that the command interpreters need to be >modified to request confirmation of potentially fatal things such >as rm * and it must be in the command interpreter as the command >itself can't know whether the list is an expanded list or a >individually entered list. There are far more general solutions. Most people have trash cans. One can recover their contents for some time, but they go away at well defined times. Too bad unix doesn't handle generations in the file system (rcs and friends are clever archivers - they are still useful in this context). Obsolete versions can be marked "deleted" so they aren't normally visible, but they can be retrieved. Then it makes sense to have a file deleter that tells you what it has done, just to reduce the chance of surprise. (Yes, there should be bozo mode for people who don't want to know or for programs that think they know what they are doing.) One should never simplify more than necessary. -andy -- Andy Freeman UUCP: {arpa gateways, decwrl, sun, hplabs, rutgers}!sushi.stanford.edu!andy ARPA: andy@sushi.stanford.edu (415) 329-1718/723-3088 home/cubicle
wcw@psuhcx (William C Ward) (11/17/87)
In article <1689@rayssd.RAY.COM> dhb@rayssd.RAY.COM (David H. Brierley) writes: >If users removing all of their files by inadvertently typing "rm *" is >a habitual problem at your site, why not make the command default to >interactive mode? The rm * disaster catches not only the absent-minded, but also the hasty and uncoordinated. I once mistyped a command like: rm *&foo instead of rm *foo (*& is a double-strike of adjacent keys!) and the machine obediently and hastily removed all files in the directory via a background process. My screams were audible many doors down the hall as I looked helplessly at the screen. What I have done to lessen future disasters of this kind is to insert the following crontab entry for other users: # Keep second copies of recent source files (*.c, *.f, *.h) in /tmp 30 * * * * nice -10 find /usr/usr -mtime -1 -name *.[cfh] -exec cp {} /tmp \; # Get rid of old /tmp files 0 2 * * * find /tmp -atime +4 -exec rm -f {} \; If incremental dumps are done at least every 4 days, this means that most source development work that can be lost is one hour's worth, if your disk doesn't crash entirely. The extra load on a small system with a little extra space and 10 or 20 users is pretty negligible, since only files which have been modified in the last hour are copied. If security is a concern, the backup files (owned by root) can be set to 600 mode. Moreover, it protects against `generic' disasters (rm, cp, cc -o, or foolish edits). This has saved me more than once now! Bill Ward Bitnet: WCW@PSUECL Noise Control Laboratory UUCP: {gatech,rutgers,..etc.}!psuvax1!ncl!wcw The Penn. State University USnail: 157 Hammond Bldg.; Fone: (814)865-7262 University Park, PA 16802
gwyn@brl-smoke.UUCP (11/17/87)
In article <1689@rayssd.RAY.COM> dhb@rayssd.RAY.COM (David H. Brierley) writes: >If users removing all of their files by inadvertently typing "rm *" is >a habitual problem at your site, why not make the command default to >interactive mode? Please don't fuck with the standard commands. If you're going to change the semantics, give it a new name and retain the old one for applications that expect the documented semantics.
roy@phri.UUCP (Roy Smith) (11/17/87)
In article <1689@rayssd.RAY.COM> dhb@rayssd.RAY.COM (David H. Brierley) writes: > Just the other day I wiped out a weeks worth of work by typing > "cc -o pgm.c" on my AT&T unix-pc. This may sound harsh, but I really have little sympathy in this case. That zapping a source file wipes out a week's worth of work implies that you don't make daily backups. Even on a PC, doing backups should be routine every day; there really is little excuse for not doing so. Things like emacs's "~" backup files (I'm not familiar with other editors; I assume this feature is available in vi, etc, as well) mitigate the damage from "rm *.c" instead of "rm *.o", and similar disasters (at the cost of some wasted disk space), but daily backups are really the bottom line. In fact, I have given serious thought to running incremental disk-to-disk dumps several times a day here to narrow the window of vulnerability from a whole day to a few hours. Yes, I know dumps on live file systems don't always work, but it's better than not doing it at all. -- Roy Smith, {allegra,cmcl2,philabs}!phri!roy System Administrator, Public Health Research Institute 455 First Avenue, New York, NY 10016
bak@csd_v.UUCP (11/18/87)
In article <763@rocky.STANFORD.EDU>, andy@rocky.STANFORD.EDU (Andy Freeman) writes: > There are far more general solutions. Most people have trash cans. > One can recover their contents for some time, but they go away at > well defined times.... I use a version of rm adapted from Wizard's Grabbag in UNIX/XENIX world. It simply prepends '#' to the file name if no swithces are listed in the command line. Thus $ rm foo creates a file #foo, while $ rm -[i|f|r] foo all work normally. Since # is the shell comment charater it is very hard to unintentionally delete files with names beginning with it. My crontab contains the line 10 3 * * 0,2,4,6 find / \( -name '#*' -o -name 'tmp.*' -o -name '*.tmp' -o -name 'temp.*' -o -name '*.temp' \) -mtime +3 -exec rm -f {} \; which deletes files beginning with '#' which have been unmodified for 3 days. If disk space is a problem you can cut down the -mtime value. This script has saved me grief on more than one occasion. -- Bruce Kern -- Computer Systems Design, 29 High Rock Rd., Sandy Hook, Ct. 06482 uunet!swlabs!csd_v!bak
ustel@well.UUCP (Mark Hargrove) (11/18/87)
> Xref: well comp.cog-eng:280 comp.unix.xenix:1083 comp.unix.wizards:5329 > > In article <1402@cuuxb.ATT.COM> dlm@cuuxb.UUCP (Dennis L. Mumaugh) writes: > [We're talking about "rm *". Guess why I have a csh alias for rm that > always asks about every file. When I'm absolutely sure that I want to > delete a number of files and I don't want to answer questions, I pipe > the whole command off to sh.] In a similar vein, we have a shell function defined in /etc/profile for our Bourne Shell users: rm(){ if [ ! -d /usr/tmp/$LOGNAME ] ; then mkdir /usr/tmp/$LOGNAME fi mv $* /usr/tmp/$LOGNAME } Then we have /usr/lbin/reallyrm linked to /bin/rm for when you really mean it. A once a week cron script cleans out /usr/tmp right AFTER a backup. This DOESN'T fix the ol' slip of the fingers that results in reallyrm * .o <---you only see the space AFTER you hit return ;-) but it HAS saved the day enough times to make it worth the 10 minutes it took to implement. Mark Hargrove U.S. TeleCenters {backbones}!hplabs!well!ustel
clif@chinet.UUCP (11/18/87)
I dunno if this is quite a human interface tale of woe, but... I recently lost my hd0 to a power supply problem. No problem, says I, once I fixed the power supply, I have a dump level 0 backup from one month back, and a crontab entry that does a dump level 2 of hd0 to a file hd1 each morning at 06:00. After restoring things from floppy, it was somewhat after midnight, and I decided to complete the task the following day. At 06:00, right on schedule, the machine did a level 2dump, over the file of good data on hd1. Pow, in one swell foop my clever method of making sure I couldn't lose any data had lost me a months worth. Moral: I dunno. Maybe don't leave the machine running unattended until you've completely fixed things up. -- ------------------------------------------------------------------------ My Opinions are my own. I can't imagine why anyone else would want them. Clif Flynt ihnp4!chinet!clif ------------------------------------------------------------------------
rapaport@sunybcs.uucp (William J. Rapaport) (11/18/87)
After wiping out one too many directories, I aliased rm to: 'mv \!:1 #\!:1' Now, it is impossible for me to execute: rm * It slows me down a bit when I do want to rm lots of stuff, but the price is well worth the insurance.
jec@nesac2.UUCP (John Carter ATLN SADM) (11/18/87)
In article <3032@phri.UUCP>, roy@phri.UUCP (Roy Smith) writes: > In article <1689@rayssd.RAY.COM> dhb@rayssd.RAY.COM (David H. Brierley) writes: > > Just the other day I wiped out a weeks worth of work by typing > > "cc -o pgm.c" on my AT&T unix-pc. > > This may sound harsh, but I really have little sympathy in this > case. That zapping a source file wipes out a week's worth of work implies > that you don't make daily backups. Even on a PC, doing backups should be > routine every day; there really is little excuse for not doing so. My multi-user systems get daily backups - my PC gets infrequent backups, except for some critical items (my LAN database). However, in the original case, it appears that the unix-pc has an old and rather braindead compiler - the ones I use (DEC 11/70, AT&T 3B2, 3B5) respond to 'cc -o file.c' with 'would overwrite source' and then abort. Getting 'cc -o' instead of 'cc -O' is very easy. -- USnail: John Carter, AT&T, Atlanta RWC, 3001 Cobb Parkway, Atlanta GA 30339 Video: ...ihnp4!cuea2!ltuxa!ll1!nesac2!jec Voice: 404+951-4642 (The above views are my very own. How dare you question them? :-)
franka@mmintl.UUCP (Frank Adams) (11/20/87)
[Not food] One of my favorite human interface design errors is in VM/CMS, where "i", typed on a line by itself, destroys your image. It stands for "ipl", you see. This happens even if you enter it on the command line of the editor. There are various ways of dealing with the problem; my preferred solution is to make "i" a synonym for some other, harmless command. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
djones@megatest.UUCP (Dave Jones) (11/21/87)
in article <1689@rayssd.RAY.COM>, dhb@rayssd.RAY.COM (David H. Brierley) says: > Xref: dlb comp.cog-eng:259 comp.unix.xenix:1008 comp.unix.wizards:4836 > > If users removing all of their files by inadvertently typing "rm *" is ... > Of course, nothing you can do will ever solve the problem completely > since even the most expert user will occasionally make mistakes. Just > the other day I wiped out a weeks worth of work by typing "cc -o pgm.c" > on my AT&T unix-pc. I had meant to use -O to invoke the optimizer. > Instead, it optimized away all of my code by giving me a message to the > effect of "no source file" and happily creating a zero length output > file called "pgm.c". I was not at all amused. I now have a shell > script in place of cc which checks all its arguments for consistency > (i.e. you can't say "-o pgm.c"). > -- > David H. Brierley > Raytheon Submarine Signal Division > 1847 West Main Road > Portsmouth, RI 02871 > > Phone: (401)-847-8000 x4073 > Internet: dhb@rayssd.ray.com > Uucp: {cbosgd, gatech, linus, mirror, necntc, uiucdcs} !rayssd!dhb I guess I had been programming about two months when it occured to me that a program should always open all the input-files that it can before it opens ANY output-files. Somebody forgot to tell the writer of your cc. Sigh. (When output is going to a disc-file, a program should write it first to a temporary, then if there is no error, move it to the real place.) It is interesting that the same principle can apply to microprocessor hardware: instructions which read all their inputs, and then write one output can be restarted from the beginning after a page-fault at any step in the instruction. The T.I. 990 microprocessor line had some instructions which were not like that. They made it hard to upgrade to virtual memory when all the competators did. So far as I know, the 990 is pretty much a dinasaur now.
msb@sq.UUCP (11/21/87)
> The rm * disaster catches not only the absent-minded ...
I thought it was about time someone expressed the opposite point of view.
If I type "rm *", it is because I want to remove all the files. No, not
all *my* files. All *the* files that I still have write permission on,
that are in the current directory. Usually no more than about 20 of them.
In short, the proper UNIX* flavored method for protecting important files
from "rm" is to turn off the write permission bit.
Now, if you want to talk about human interface disasters and "rm" ...
Tell me how come "rm ... &" causes the -f flag to be assumed, and thus
removes the write-protected files after all? Write-protecting the directory
stops it, but this is often not feasible. I think the gods nodded on that one.
Mark Brader, utzoo!sq!msb, msb@sq.com C unions never strike!
*"UNIX is a trademark of Bell Laboratories" is a religious incantation.
That it no longer reflects reality is a bug in reality.allbery@ncoast.UUCP (11/21/87)
As quoted from <3032@phri.UUCP> by roy@phri.UUCP (Roy Smith): +--------------- | In article <1689@rayssd.RAY.COM> dhb@rayssd.RAY.COM (David H. Brierley) writes: | > Just the other day I wiped out a weeks worth of work by typing | > "cc -o pgm.c" on my AT&T unix-pc. | | This may sound harsh, but I really have little sympathy in this | case. That zapping a source file wipes out a week's worth of work implies | that you don't make daily backups. Even on a PC, doing backups should be | routine every day; there really is little excuse for not doing so. +--------------- NO REASON?! When it takes 50 floppies to back up the HD, there is VERY MUCH a reason. (Tape? You got $1500 free to give me for a tape drive?) I back up my home directory, and if the disk crashes I just do a full reinstall. This is no slower than reloading lots of disks.... For the "rm" problem, I think I've got a solution. The idea comes from a cross between existing "rm/unrm" programs and fsck, and deals with links as well. (1) For every mounted filesystem PLUS the root, create a directory called "wastebasket" or some such. (2) The program "del" (NOT "rm" -- you'll screw up programs which invoke rm via system(), such as the System V spooler) links a file into the wastebasket directory for a filesystem by its inode number, and writes a line into an index file consisting of inum, path, and date and time. Maybe also the user who did it. (3) The program "undel" links the file back out of the wastebasket to its original path, via the index. (4) A program "expdel" (expunge deleted files) uses the index to choose files del'ed more than some specified or default time ago and unlinks them. By using rename() under BSD or SVR3, or using root privs under SVR2 or older, this can be generalized to directories as well, giving a safe rmdir as well. Note that this retains all links (except symbolic ones, but that's part and parcel of the problems with a symlink -- not to start THAT war again, but there isn't a whole lot to be done about it), and the expunge process does not have to search every user's home directory either. The result is a reversible rm which doesn't have any of the drawbacks of current ones. -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,{sun,cbosgd}!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc
dave@onfcanim.UUCP (11/22/87)
In article <3032@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: > >In fact, I have given serious thought to running incremental >disk-to-disk dumps several times a day here to narrow the window of >vulnerability from a whole day to a few hours. Yes, I know dumps on live >file systems don't always work, but it's better than not doing it at all. There is an even better way. We run a "backup daemon", originally written by Ciaran o'Donnell at Waterloo, and still in use there, which is called from the crontab (every hour in our case) to scan a list of filesystems looking for files that were changed since it was last run. When it finds one, and it isn't too large and its name doesn't pattern-match a list of "not worthwhile" names like "*.out", it copies it into a backup fileystem. If the original filename was /u/dave/film.c, the copy will be named /backup/u/dave/film.c/Nov20-19:01. If I change the file again, it will be backed up again an hour later, with a filename that reflects the changed time or date. Then, when I trash a file through carelessness, I have a whole "history" of backup copies to go back through, so even if I introduced a bug 5 hours ago, I can generally get back the code before that. And I don't have to run "restore" to look for it; I just chdir to /backup/u/dave/film.c and look around. The /backup filesystem must be dedicated to the use of the backup program, since it keeps it from filling up by deleting the oldest files as necessary to make room for the new ones. We use a 30-Mb partition, which seems to keep stuff around for about a month on a system with 4 people writing code. The only way I still lose files is if I clobber them within the first hour of working on them (often it's withing the first 2 seconds when it happens!) and the file hadn't been touched for 2 months before that, so all old copies have been deleted. So then I have to get out the tapes. But it works most of the time, gives me a backup every hour of a file that I am changing frequently, and requires no work on my part at all.
mkhaw@teknowledge-vaxc.ARPA (Mike Khaw) (11/22/87)
I was reminded of the following recently:
HP keyboards: is the caps lock key in the "on" state or "off" state? If
you're REAL lucky, you have an on-screen "softkey label" that is enabled,
one of which shows the state of the caps lock key. Otherwise ... the key
itself doesn't physically lock, there's no caps lock status light on the
keyboard, and here's the kicker -- if caps lock is on and you press shift,
it makes the alpha key transmit LOWERcase. I could never tell if caps lock
was on or off until I hit an alpha key. Odds are 50/50, right? Murphy's
Law says it's never what you think it is.
HP streamer cartridge tape drives: You insert the cartridge, it insists on
winding to EOT. You then run a tape program -- whoops, it's at the wrong
end ... better wait while it winds to BOT. You want to eject the tape: it
has to wind to BOT first -- whoops, it's not there ... better wait again.
Worst case: put a tape in to read something off it. Uh oh, did I write
protect it? Too late, the drive won't let me eject the tape until it's done
winding to EOT. When it finally gets to EOT, it has to wind to BOT before
I can have my tape back. Now I can make sure it's write protected. Put the
tape back in ... guess what? Wait to wind to EOT (I was at BOT). Run the
tape read program ... wrong end, wait to wind to BOT, etc. How many minutes
did I just waste waiting for this all this tape motion?
Mike Khaw
--
internet: mkhaw@teknowledge-vaxc.arpa
usenet: {uunet|sun|ucbvax|decwrl|uw-beaver}!mkhaw%teknowledge-vaxc.arpa
USnail: Teknowledge Inc, 1850 Embarcadero Rd, POB 10119, Palo Alto, CA 94303TDTRUE@pucc.Princeton.EDU (Thomas True) (11/23/87)
In article <2572@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: >One of my favorite human interface design errors is in VM/CMS, where "i", >typed on a line by itself, destroys your image. It stands for "ipl", you >see. This happens even if you enter it on the command line of the editor. Although VM/CMS has a number of flaws in its user interface, the one mentioned is not currently one of them. Within the editor (XEDIT), 'i' puts you in 'INPUT MODE' to continuously enter lines of text. XEDIT also lets you set things so that a user must explicitly issue a command to the operating system. Outside the editor, 'i' or for that matter 'ipl' will just give you the error 'OPERAND MISSING OR INVALID'. Of course, if you put any text after the I, the system will try to IPL with what you gave it . . . . Tom True Princeton University
jc@minya.UUCP (John Chambers) (11/23/87)
In article <6690@brl-smoke.ARPA>, gwyn@brl-smoke.ARPA (Doug Gwyn ) writes: > In article <1689@rayssd.RAY.COM> dhb@rayssd.RAY.COM (David H. Brierley) writes: > >If users removing all of their files by inadvertently typing "rm *" is > >a habitual problem at your site, why not make the command default to > >interactive mode? > > Please don't fuck with the standard commands. If you're going to > change the semantics, give it a new name and retain the old one > for applications that expect the documented semantics. I'll second that. Back in high-school shop, it was common to point out to the students that there were a lot of very dangerous tools around. Most of them had some sort of safety shields. The teachers commented that professionals usually took the shields off in their own shops, as they interfere with efficient use (and sometimes damage the material). But we weren't professionals; we would leave the shields on. The computer field hasn't learned this lesson. Among all the clumsy and difficult-to-use operating systems, we have Unix as one of the few examples of a system designed by and for professionals. But we somehow insist on handing the raw, unshielded tools (like rm) to pros and novices alike. If we had the sense of the average high-school shop instructor, we would realize that novice users shouldn't be handed sharp tools like rm. We would supply them with things like the Macintosh's trash cans or VMS's versions or some sort of protection. But we would at the same time realize that the professionals among us want and need good tools for doing their jobs, and the bare, unshielded tools are right for them. Unix can support this sort of stuff easily. I've done it on lots of systems. Unlike some other systems, there is no problem with providing multiple libraries (and multiple command languages) that are "friendly" to multiple classes of users. Implementing "delete" by renaming is quite trivial. Implementing multiple versions of files is also quite trivial. If a script isn't fast enough, these are easily coded in C. There is little point in modifying a command like 'rm' to be friendly to novices. For non-hackers, this is the wrong name. If you are going to build safety features in, you should at the same time pick a new, user-friendly name such as 'delete'. In that way, you will help the novice users, and you won't mess up any of the thousands of scripts floating around that need rm to get their job done. One thing we certainly don't need is to discover that all our carefully tailored, user-friendly scripts are now asking the hapless user if he really wants to "rm /tmp/vSl5437a". And when my script decides to clean up the garbage in its scratch directory, it is decidedly unfriendly to have the user forced to verify the "rm *" when he doesn't even know that the directory exists. It is also unfriendly to me to force me to go through old scripts and change the calls on things like rm because some turkey decided to make it more friendly to novices. I like Unix's terse, powerful commands. They're just what I need to get a lot of work done easily. Please don't mess them up in a misguided effort to save some novices a bit of heartbreak. You'd be doing them and me a big favor by implementing a new command that does their job right, and leaves me with my sharp tool. BTW, I also have some very sharp knives in my kitchen. Like most parents, when there were toddlers around, I kept them well off the floor. Now that the toddlers are in high school, I feel free to keep some of them on a lower shelf. I have no intention of ever replacing them with "safe" knives, even if I do nick myself once in a great while. [I've taken the liberty of responding only in comp.cog-eng; groups like unix.wizards shouldn't be harassed by stuff like this. Maybe some of the usenet admins out there should try to get this discussion out of the irrelevant newsgroups.] -- John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
cameron@elecvax.eecs.unsw.oz (Cameron Simpson "Life? Don't talk to me about life.") (11/23/87)
In article <1402@cuuxb.ATT.COM>, dlm@cuuxb.ATT.COM (Dennis L. Mumaugh) says: | After that is fixed we can talk about Jim Gillogly's spelling | corrector shell. | -- | =Dennis L. Mumaugh | Lisle, IL ...!{ihnp4,cbosgd,lll-crg}!cuuxb!dlm I once used something calling itself `nsh' on a System V machine, and typed $ cd thnig and thought "bother, I meant `thing'" and was then disconcerted when it said path/thing $ back at me. It had fixed the transposed chacters and dropped me in the right spot! Hopefully it only happened in interactive mode, but it was very disconcerting. - Cameron Simpson
nortond@mosys.UUCP (Daniel A. Norton) (11/23/87)
Distribution: On the version of Unix V.3 here (CTIX), when a new user enters a password he/she will invariably choose a password of less than six characters, to which the system replies: Password is too short - must be at least 6 digits Fortunately, they do not usually notice the word "digits" (as opposed to characters). Unfortunately, when they attempt to satisfy the program, it usually replies: Password must contain at least two alphabetic characters and at least one numeric or special character. In other words, the first "help" message was not specific enough as to the password requirements. I would not expect a BNF description of what to type in here, we must assume that the user has _some_ intuition, but seriously folks. -- Daniel A. Norton nortond@mosys.UUCP c/o Momentum Systems Corporation ...uunet!mosys!nortond 2 Keystone Avenue Cherry Hill, NJ 08003 609/424-0734
jfh@killer.UUCP (11/24/87)
In article <1987Nov21.014754.19660@sq.uucp>, msb@sq.UUCP writes: > > The rm * disaster catches not only the absent-minded ... > > I thought it was about time someone expressed the opposite point of view. > > If I type "rm *", it is because I want to remove all the files. No, not > > Mark Brader, utzoo!sq!msb, msb@sq.com C unions never strike! I cast my vote for doing the remove. I'd also like rm to consider asking me to confirm the decision if I should happen to delete, say, more than 10 or 15 files. Having the first few lines in main() be something like, fflg = (argc > 15) || fflg; might be nice, or having a prompt, ala' MessyDos (yick) might be nice. Thoughts? - John. -- John F. Haugh II SNAIL: HECI Exploration Co. Inc. UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600 ...!ihnp4!killer!rpp386!jfh Dallas, TX. 75243 "Don't Have an Oil Well? Then Buy One!" (214) 231-0993
goudreau@xyzzy.UUCP (11/25/87)
In article <1987Nov21.014754.19660@sq.uucp> msb@sq.UUCP (Mark Brader) writes: >> The rm * disaster catches not only the absent-minded ... > >I thought it was about time someone expressed the opposite point of view. > >If I type "rm *", it is because I want to remove all the files. No, not >all *my* files. All *the* files that I still have write permission on, >that are in the current directory. Usually no more than about 20 of them. >In short, the proper UNIX* flavored method for protecting important files >from "rm" is to turn off the write permission bit. I'm sorry if that's what you want, because that's not what your system is going to do. I quote from the rm(1) entry in the 7th Edition Programmer's Manual: "Removal of a file requires write permission in its directory, but neither read nor write permission on the file itself." Protecting your files in this way is thus an all-or-nothing method, per directory. A better to way to understand this is to think about what's really going on at the directory level. When you remove (or move) a file within a directory, you never need to read or write the file itself. You need to rewrite the directory because you wish to change the contents of the directory file (its dir entries), and so write permission in the directory is what is required.
barnett@steinmetz.ge.com (Bruce G Barnett) (11/25/87)
In article <2205@killer.UUCP> jfh@killer.UUCP (The Beach Bum) writes: [ rm could ask for comfirmation if more than 15 files were to be deleted] | Having the first few lines in main() be something like, | | fflg = (argc > 15) || fflg; | |might be nice, or having a prompt, ala' MessyDos (yick) might be nice. | |Thoughts? Don't change rm when you could have a shell script do the same thing! Sheesh!
franka@mmintl.UUCP (Frank Adams) (11/26/87)
In article <3911@pucc.Princeton.EDU> TDTRUE@pucc.Princeton.EDU writes: |In article <2572@mmintl.UUCP>, franka@mmintl.UUCP (Frank Adams) writes: |>One of my favorite human interface design errors is in VM/CMS, where "i", |>typed on a line by itself, destroys your image. It stands for "ipl", you |>see. This happens even if you enter it on the command line of the editor. | |Although VM/CMS has a number of flaws in its user interface, the |one mentioned is not currently one of them. Within the editor |(XEDIT), 'i' puts you in 'INPUT MODE' to continuously enter lines |of text. Input mode is relatively new to XEDIT. I think it had just become available shortly before I switched jobs and stopped using the system. |XEDIT also lets you set things so that a user must explicitly issue a |command to the operating system. Yes, and CMS lets you set things so that a user must explicitly issue a command to CP. Unless these are the default, they don't help the naive user. They aren't the default. |Outside the editor, 'i' or for that matter 'ipl' will just give |you the error 'OPERAND MISSING OR INVALID'. Of course, if you |put any text after the I, the system will try to IPL with what |you gave it . . . . My memory may be faulty on this; I thought I remembered it clearing memory first, and then checking for the operand. On the other hand, what you describe does sound familiar. It's bad enough, anyhow. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
msb@sq.UUCP (11/27/87)
Having had my knowledge of UNIX* insulted in public, I feel obliged to reply in public. This is positively my last posting on the topic. [And if you see it twice, it's not MY fault, I canceled the first one.] > >In short, the proper UNIX flavored method for protecting important files > >from "rm" is to turn off the write permission bit. > I'm sorry if that's what you want, because that's not what your system > is going to do. And then he quotes the V7 manual at me, and explains why permissions work as they do. Well, he should have read one more paragraph: # If the a file has no write permission and the standard input is a # terminal, its permissions are printed and a line is read from the # standard input. If that line begins with `y' the file is deleted, # otherwise the file remains... This is precisely the kind of interactive prompting that one school of "rm is too powerful" users like. But you only get it when you want it. Sure, write protecting the file doesn't affect what rm has *permission* to do ... it affects what it *will* do. As I said in my original posting, I do consider it a misfeature that if stdin is NOT a terminal then rm proceeds regardless of the file's permissions. I think the -f flag should be required in that mode also. (I also think that having said that should have been sufficient prevention from having UNIX basics explained to me on the net.) While I'm posting, I'll add the bit I left out the first time. I have made it a habit *not* to hit Return instantly upon typing a line that has both "rm" and "*" in it. I pause and reread it. It's an easy habit to establish, and it's all the protection I think I need against "rm * .o". Mark Brader "Male got pregnant -- on the first try." utzoo!sq!msb Newsweek article on high-tech conception msb@sq.com November 30, 1987 *"UNIX is a trademark of Bell Laboratories" is a religious incantation.
hubcap@hubcap.UUCP (Mike Marshall) (12/01/87)
In article <1987Nov27.011955.10801@sq.uucp>, msb@sq.uucp (Mark Brader) writes: > While I'm posting, I'll add the bit I left out the first time. I have > made it a habit *not* to hit Return instantly upon typing a line that > has both "rm" and "*" in it. I pause and reread it. It's an easy habit > to establish, and it's all the protection I think I need against "rm * .o". I agree. I can be as scatter brained as they come, but I have cultivated the above habit, and I don't think I have EVER lost any files with "rm * .o" (or whatever). I always automatically reread whatever I've typed when using rm, it's not a hassle, cause I do it without thinking. Another habit that I have extablished is "rm -i" whenever I am su'ed to root. You can take your good habits with you to a new environment... but maybe not your aliases :-). -Mike Marshall hubcap@hubcap.clemson.edu ...!hubcap!hubcap
allbery@ncoast.UUCP (12/01/87)
As quoted from <392@xyzzy.UUCP> by goudreau@xyzzy.UUCP (Bob Goudreau): +--------------- | In article <1987Nov21.014754.19660@sq.uucp> msb@sq.UUCP (Mark Brader) writes: | >If I type "rm *", it is because I want to remove all the files. No, not | >all *my* files. All *the* files that I still have write permission on, | | I'm sorry if that's what you want, because that's not what your system | is going to do. I quote from the rm(1) entry in the 7th Edition | Programmer's Manual: | | "Removal of a file requires write permission in its directory, | but neither read nor write permission on the file itself." +--------------- True enough -- at the level of unlink(). But if you'll unalias (or un- function, if you're a System V type) rm for a moment and try to "rm" a file which is write-protected without using the "-f" flag, you'll see: bsd% rm foo foo 444 mode _ $ rm foo #system V foo: 444 mode ? _ The biggest problem with this is that it's rather difficult to edit a C program that's been "rm"-proofed in this manner.... -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc
franka@mmintl.UUCP (12/01/87)
[I have directed follow-ups to comp.cog-eng only.] In article <1987Nov27.011955.10801@sq.uucp> msb@sq.UUCP (Mark Brader) writes: >While I'm posting, I'll add the bit I left out the first time. I have >made it a habit *not* to hit Return instantly upon typing a line that >has both "rm" and "*" in it. I pause and reread it. It's an easy habit >to establish, and it's all the protection I think I need against "rm * .o". I agree. Without having particularly thought about it, I do the same thing. I suspect that most experienced programmers do, too. This, of course, makes it no less a human interface problem. The only people who can fix the problem are the people who don't need to. -- Frank Adams ihnp4!philabs!pwa-b!mmintl!franka Ashton-Tate 52 Oakland Ave North E. Hartford, CT 06108
brianc@cognos.uucp (Brian Campbell) (12/02/87)
In article <1987Nov27.011955.10801@sq.uucp> msb@sq.UUCP (Mark Brader) writes: > In short, the proper UNIX flavored method for protecting important files > from "rm" is to turn off the write permission bit. Marking selected files as read-only is often useful for protecting files in the singular sense. However, it is also possible to protect an entire directory from accidental erasure with: touch \! chmod -w \! Now, when the careless (?) user enters "rm * .o" or any variation thereof (excluding the addition of -f), the first file rm will encounter will be ! (unless someone has filenames starting with spaces or other unprintables). rm will ask if the user really wants to delete this file. At this point, an INTR will stop rm from deleting any files at all; answering n will simply tell rm not to delete that single file. > As I said in my original posting, I do consider it a misfeature that > if stdin is NOT a terminal then rm proceeds regardless of the file's > permissions. I think the -f flag should be required in that mode also. > (I also think that having said that should have been sufficient > prevention from having UNIX basics explained to me on the net.) I do not think this is a "misfeature". With shell scripts and system() calls I have a chance after I have typed the command to verify that it is indeed what I wanted. When interactive, its too late after I've pressed return. -- Brian Campbell uucp: decvax!utzoo!dciem!nrcaer!cognos!brianc Cognos Incorporated mail: POB 9707, 3755 Riverside Drive, Ottawa, K1G 3Z4 (613) 738-1440 fido: (613) 731-2945 300/1200, sysop@1:163/8
dave@lsuc.uucp (David Sherman) (12/03/87)
cameron@elecvax.eecs.unsw.oz (Cameron Simpson) writes: >I once used something calling itself `nsh' on a System V machine, and typed > $ cd thnig >and thought "bother, I meant `thing'" and was then disconcerted when it said > path/thing > $ >back at me. It had fixed the transposed chacters and dropped me in the right >spot! Hopefully it only happened in interactive mode, but it was very >disconcerting. We have that in our Bourne shell here. You get used to it very quickly, and it's VERY handy. Yes, it only works in interactive mode. As far as I remember, the origins of spelling-correction for chdir in sh go back to Tom Duff adding it to the v6 shell at U of Toronto around 1976 or so. I then pulled out td's spname() routine and began plugging it into other utilities on our v6 11/45, when used interactively (p, cmp, and a few others). The routine accompanied Rob Pike on his travels when he left U of T, and it shows up in Kernighan & Pike (with credit to Duff, I believe; don't have a K&P handy). In the original version, it would ask you: $ cd /ibn cd /bin? y $ The version of sh currently on our system (I got this part from sickkids!mark) doesn't bother asking, which I think is right because you often type ahead and don't want some command swallowed as an answer to "cd foo?". It just does it: $ cd /ibn cd /bin $ If anyone with a source license wants the code in sh to implement this, let me know. It's pretty trivial once you have spname(3), which we use all over the place now (more(1), for example). David Sherman The Law Society of Upper Canada -- { uunet!mnetor pyramid!utai decvax!utcsri ihnp4!utzoo } !lsuc!dave Pronounce it ell-ess-you-see, please...
jhh@ihlpl.UUCP (12/04/87)
In article <6304@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon Allbery) writes: > bsd% rm foo > foo 444 mode _ > > $ rm foo #system V > foo: 444 mode ? _ > > The biggest problem with this is that it's rather difficult to edit a C > program that's been "rm"-proofed in this manner.... A popular editor here at Bell Labs (Montgomery's emacs) is very easy to use on 444 files, as long as the directory is writable. When a write operation is requested, and the file is not writable, it asks if the user wants to write anyhow, and if so, it removes the file, creates a new one, and resets it to the original ownership and permissions. I find that much easier than being frustrated with vi or ed leaving me stuck in either readonly mode, or any other similar state.
wcs@ho95e.ATT.COM (Bill.Stewart) (12/07/87)
In article <771@hubcap.UUCP> hubcap@hubcap.UUCP (Mike Marshall) writes:
:I agree. I can be as scatter brained as they come, but I have cultivated the
:above habit, and I don't think I have EVER lost any files with "rm * .o"
Must be nice. I had a spurious file once, called * , and removed it.
I realized what I'd done about the time the $ came back; this was when
I learned about nightly backups (the administrators did them), and rm -i.
At Purdue, the local version of 4.*BSD had modified rm to move things
to /tmp/graveyard instead of really deleting them; they'd stick around
48 hours or so. You could use the real rm if you wanted to. Of
course, this doesn't prevent other ways of trashing files, though
noclobber helps. One of the few things I appreciate about VMS is the
file versioning; every time you modify a file, it creates a new copy of
it (I assume at open-file-for-writing time?). Even a one-deep automatic
backup would be helpful; emacs does this but vi and ed don't.
--
# Thanks;
# Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs