Text File

Aucbvax.3277 fa.unix-wizards utzoo!decvax!ucbvax!unix-wizards Wed Sep 23 03:16:32 1981

>From BH@MIT-AI Tue Sep 22 17:51:57 1981 1. Random questions:

My users have long wanted a "safer rm" that would make it less easy to destroy oneself accidentally. The problem is that by the time rm starts, the fact that you typed "rm *" rather than a list of a zillion explicit names is lost. I am thinking about installing a feature in shell (and/or csh) which would place in the environment of a process a copy of the command line which invoked it, UNPARSED. Then rm could be as clever as it liked in deciding whether or not to ask for confirmation. Has anyone done anything like this, and are there any suggestions about pitfalls or embellishments? (On a related topic, I've sometimes wished for a way that a program could have a mode bit which told the shell not to parse the command line at all, so that non-shell-syntax commands would be possible.)

It would be awfully nice if one could say something like restor x foo/* There are two problems with this: first, if the dump is of a structure other than root, the name which must be given to restor isn't the actual filename, but the filename minus mount prefixes. Second, the reason you're restoring the file is that it isn't on the disk anymore, so the shell can't expand the '*'. It would be nice if restor itself understood * and searched the dump tape's directory rather than the disk directory. Anyone done any work on this?

I recently had a major disk disaster which required starting all over again and then restoring complete dump tapes. For my /usr structure I had three tapes, a full dump and two incremental dumps. The trouble was that the full dump nearly filled the disk, and I had to delete some stuff which had been deleted in real life since that full dump, order for the incremental dumps to fit. But I later discovered that deleting those files (mainly an Empire sector file, grumble, grumble) led to bunches of icheck/dcheck problems. Can someone explain why, and what I should have done instead?

2. Brief flame about what does or doesn't belong in the kernel

I am a system programmer with over 10 years of experience, and two years of Unix experience, and I'm reasonably smart. Nevertheless, I've made errors which led to security problems in my Unix system. My users are less sophisticated than I. I am in favor of systems which make it easier not to make such mistakes, even if they are less "pure", e.g. chown doing a theorietically unrelated chmod to turn of set?id. I am even in favor of the kernel disallowing most punctuation characters in filenames! Things like '/'+0200 are particularly worthy of disallowal. This opinion is not formed lightly; I grew up with the MIT ITS systems in which "not protecting the user from himself" is a religion, to which I have long subscribed. I still do, to an extent, but there are hazards in Unix which frighten me, such as the ones recently discussed here.

A major related change I'd like to see is to not free up the old version of a file until a newly CREATed version is successfully CLOSEd, as in most DEC operating systems. I realize this isn't so easy.

----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen <jgoerzen@complete.org> of http://communication.ucsd.edu/A-News/

This Usenet Oldnews Archive article may be copied and distributed freely, provided:

1. There is no money collected for the text(s) of the articles.

2. The following notice remains appended to each copy:

The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.