Re: Autoloading of compctl from dbm database file.

[Fung-Chai Lim <fclim@xxxxxxxxxxxxxx>]

In <8922.199611301640@xxxxxxxxxxxxxxxxxxxxxxx>
on Sat, 30 Nov 1996 16:40:31 +0000 (GMT)
Zefram <zefram@xxxxxxxxxxxxxxxxx> 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.