From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9914 invoked from network); 30 Nov 1996 16:49:28 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by coral.primenet.com.au with SMTP; 30 Nov 1996 16:49:27 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id LAA18133; Sat, 30 Nov 1996 11:40:02 -0500 (EST) Resent-Date: Sat, 30 Nov 1996 11:40:02 -0500 (EST) From: Zefram Message-Id: <8922.199611301640@stone.dcs.warwick.ac.uk> Subject: Re: Autoloading of compctl from dbm database file. To: fclim@singnet.com.sg (Fung-Chai Lim) Date: Sat, 30 Nov 1996 16:40:31 +0000 (GMT) Cc: zsh-workers@math.gatech.edu In-Reply-To: <9611301332.AA04891@fclim.singnet.com.sg> from "Fung-Chai Lim" at Nov 30, 96 09:31:35 pm X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]8503.47 X-US-Congress: Moronic fuckers Content-Type: text Resent-Message-ID: <"Sb0jt3.0.GR4.XD6eo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2500 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Some general comments. First, those compctls not currently in the distribution are worth adding. The example alias file, however, is a very bad idea, and should not be included. We already have a function autoloading facility. Aliases are cheap to store, usually short, and people don't have so many of them. I think it is therefore not worth adding the database autoloading for them. However, a dbm database may be a good solution to the problem of autoloading compctls. The idea of creating a single global database is flawed. These databases *must* be individual. (However, the capability to use several database files at once, in a path structure, to allow sharing of compctls would be good. Automatic installation of a standard database of compctls would then be justifiable.) All we really need is the extra builtin to allow saving and autoloading of compctls, and it is then easy enough to edit the database by hand from a normal shell. You limit the code to gdbm, because it does locking. I suggest that if we use code like this, that we handle standard dbm as well, either doing locking ourselves (with more autoconfed code) or ignoring the issue (after all, the databases won't be changing *that* often). -zefram