> 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.
You may not want that. Fine; you don't have to use it. Even the
strawman above doesn't make it impossible, nor even very difficult, to
get that; you just alias rm to rm -y, or in the variant I sketched
above, you don't alias rm to rm -warn-about-* while we do.
[Genera
"command-line"]
Well, if you want that, just write a shell implementing
that.
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.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTML mouse at
rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B