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 <
[email protected]>
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.
