17 Dec
2011
17 Dec
'11
2:31 p.m.
On Sat, Dec 17, 2011 at 11:34:46AM -0500, Mouse wrote:
And how is rm supposed to know which file deletions are ok and which ones
are dangerous? It is just a dumb machine, it can't read your mind ...
Cannot be done as part of the rm program, impossible for the obvious
reason. What you can do is patch $SHELL_OF_CHOICE to insert some well-
meaning do-what-I-say logic for this case.
This is actually missing much of the point, I think. It is somewhere
between difficult and impossible to do that in Unix, because the Unix
design enforces a fairly hard separation between the shell and the
commands it runs. Doing this requires inventing some way to -
interactively - get information flowing between the shell and the
command that might be getting run without/before actually pulling the
trigger on the command in question. This is a lot easier to do in a
Lisp world, because everything is in the same Lisp world, so, for
example, "commands" can be decorated with advice and properties and
such explaining to the CLI how to do this.
I'm not sure what tack I'd take to build such a thing in Unix. But I
think it is a very productive idea to think about it; even though I
don't like that style of interaction on a Lisp Machine, the reasons
apply somewhere between far less and not at all to Unix, and the
infrastructure necessary to support it in Unix would enable a lot of
other interesting stuff - unless you do it all as a huge collection of
special cases in the wrong places, which, in the case of rm, is where
we came in.
Well, you can still do it the way it probably was done on the Lisp
machines: just build most of the functionality into the command
interpreter and only run external programs when explicitly ordered
to do so ("run firefox", "run gimp").
Kind regards,
Alex.
--
"Opportunity is missed by most people because it is dressed in overalls and
looks like work." -- Thomas A. Edison
> Is it
annoying to anyone to either answer "y" to an "Are you sure?"
> prompt or type in "rm -y *" to autoconfirm in these few cases?
Bad idea, breaks the generic user interface
assumption that the
machine just goes and does what it is being told instead of nagging
you with "are you really sure?" prompts in the default case.
Unix standard: the training wheels are off, the
user is assumed to
know WTF he/she/it is doing. If you want the training wheels, switch
them on explicitly, but don't annoy the experts all the time. ;-)
There is some truth to this; it would be defensible to instead make rm
grow a -warn-about-* option (presumably not spelled quite that way :)
rather than warning by default and having a -don't-warn-about-* option
(spelled -y in the above strawman). In that case
of rm, the "training wheels on" mode is already
available, just use "rm -i".
This is completely misunderstanding the point. rm -i warns about every
removal, even the completely innocuous ones. That may be what you
want, but it's not what we ("we" = "me and, IIUC, Josh") want.
We want
a mode of operation in which most rm commands do exactly what you say,
just go off and work, but in the case where the arglist as typed
contains a bare *, it requires confirmation. [Genera "command-line"]
Well, if you
want that, just write a shell implementing that.