Path: utzoo!attcan!uunet!husc6!encore!bzs@encore.com
From: bzs@encore.com (Barry Shein)
Newsgroups: comp.unix.wizards
Subject: Re: fixing rm * (was: Worm/Passwords)
Message-ID: <4232@encore.UUCP>
Date: 18 Nov 88 20:50:29 GMT
References: <22401@cornell.UUCP> <4627@rayssd.ray.com> <8563@rpp386.Dallas.TX.US> <125@embossed.UUCP> <672@quintus.UUCP> <1232@atari.UUCP> <684@quintus.UUCP>
Sender: news@husc6.harvard.edu
Reply-To: bzs@encore.com (Barry Shein)
Organization: Encore Computer Corp
Lines: 19
In-reply-to: ok@quintus.uucp (Richard A. O'Keefe)

At first I was skeptical but the more I think about the expandcheck
idea the more I like it, it can be implemented in some reasonable way.

There's even precedent, like noclobber, so I don't see any look and
feel problem with it (ie. some things like this are a stench in the
nose of god, this isn't.)

A very similar proposal would be more like the CMU Csh (and I believe
the Korn shell) which echo back history substitutions and wait for
confirmation <NL>, I could imagine doing (OPTIONALLY) the same for
wildcard matches past a certain threshold...

The only possible objection to any of this that pops to mind is
transparency between shell scripts and interactive sessions but that's
easy, it should always start out as false/zero/infinity and if set
will do its thing (heck, if it confirmed to /dev/tty it could be
useful in scripts.)

	-Barry Shein, ||Encore||