Re: Distribution terms

[Zefram <A.Main@dcs.warwick.ac.uk>]

>                                           And in zsh-3.1 we have to find
>out a portable way to use dynamically loadable modules.  After that anyone
>can write a plug-in for zsh and can implement any feature he wants.  But
>such features should not blow up zsh.

I doubt that you'll find a way to do dynamic loading on every Unix.  It
might be best to simply restrict such features to Unices where the ELF
library is available (dlopen(), etc.) -- this would avoid a lot of
complication.


>                                       It would be a good idea to better
>modularise the existing zsh code, make a few things optional (fo rexample
>zle and completion).

I think it would be a good idea to have a configure-time option to
exclude ZLE, even where it can't be dynamically loaded.  Simple
conditional compilation could do this.  We might also want to consider
a configuration option to build a restricted shell -- this is a major
feature that most other shells already have.

Another thing we might want to do is to optionally have basic
file-manipulation commands (mv, rm, etc.) as builtins.  Maybe some
administration commands (mount, mknod) too.  The purpose of this would
be that we could have a statically-linked zsh in /sbin for when the
system is hosed.  (I'd support making sync a builtin even in the
standard version.)

>                      I do not know how much is the ovehead caused by a big
>executable.  When zsh is used as a scipt interpreter on a demand-paged
>system only the parts necessary run a script will be loaded so it may not
>give any real improvement.

There's not much speed improvement, and actually loading a module
separate from the executable will cause a penalty.  This penalty won't
be a problem unless it is incurred on every invocation -- we should
definitely avoid doing this.

-zefram