From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16283 invoked from network); 1 Dec 1996 13:41:35 -0000 Received: from euclid.skiles.gatech.edu (list@130.207.146.50) by coral.primenet.com.au with SMTP; 1 Dec 1996 13:41:35 -0000 Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id IAA05295; Sun, 1 Dec 1996 08:28:26 -0500 (EST) Resent-Date: Sun, 1 Dec 1996 08:28:26 -0500 (EST) From: Fung-Chai Lim Message-Id: <9612011323.AA00468@fclim.singnet.com.sg> Subject: Re: Autoloading of compctl from dbm database file. To: zsh-workers@math.gatech.edu (Z Shell workers mailing list) Date: Sun, 1 Dec 1996 21:22:43 +0800 (SGT) In-Reply-To: <8922.199611301640@stone.dcs.warwick.ac.uk> from "Zefram" at Nov 30, 96 04:40:31 pm X-Mailer: ELM [version 2.4 PL22] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"LANGC3.0.cI1.vVOeo"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2504 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu In <8922.199611301640@stone.dcs.warwick.ac.uk> on Sat, 30 Nov 1996 16:40:31 +0000 (GMT) Zefram writes: > 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. First of all, remember my patch is only a SAMPLE IMPLEMENTATION, meant as a sort of request for comments. I started with just the idea of autoloading compctl. Later on, I added the others (not much extra work) because of the -K compctl flag. If that compctl is autoloaded, then its associated function should also be. I did not extend my code to store arrays to cater for the -k compctl flag. I shipped the patch out as it is because I wanted to know what you guys think about autoloading from a dbm file. Autoloading arrays and others would be easy to code. Anyway, global aliases can be used for arrays. Having aliases and functions in the database can be useful. Remember my example, putting ZDBFILE=database zdb -auf at the top of any shell script is enough to access aliases and functions. > 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. The compctl command is a complicated beast; I don't understand most of the doc on it. The idea behind the global database is for a compctl guru to maintain it for the benefits of other users. Although the user is allowed to, I don't think it is good idea for each user to have several dbm files as it would be harder for him to maintain. Instead, one file with multiple namespaces. Initially, I was thinking of subdividing each namespace to support the varieties of platforms, etc. Consider the psg() function. And suppose the database is to be shared by both SysV and BSD systems. Using only one function definition would mean a fatter and hence slower function. I was thinking of copying the way the folks at X11 had incorporated locale information into their XAPPLRESDIR, et al, for the syntax of the path to specify the search order of the subdivisions within a namespace. I gave up the idea of subdivisions because it was too difficult to contemplate. (One trick to write the psg() function is to put a redefinition inside its definition; the redefinition is slimmer, restricted to the platform. See my Database/cd.func) > 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). I don't understand what you mean by `as well'. Are you saying that the shell understands various dbm packages? Or use whatever dbm package that comes with the system? The latter may not be a good idea because the database may be shared over a distributed file system by systems of different architectures. The database must be portable over networks. I think one of the public domain dbm packages should be selected and either the source code is distributed together with zsh or a pointer is given on where the user can get hold of it. Having said that, I think that if the 4BSD's DB package is selected (I vote for it), then a stripped down version is bundled in, similar to what Keith Bostic have done in nvi. After all, not all 3 mechanisms offered by the package are needed. Finally, I don't know enough of the innards of a dbm file to comment on not locking. I agree that saving to the databases is a rare event. However, reading them can be frequent, especially when they are shared. I wonder if the *shell* will be corrupted when fetching data from a dbm file at a time when the file changes size. Regards, fclim.