Zsh Mailing List Archive
Messages sorted by:
Re: Distribution terms
- X-seq: zsh-workers 2085
- From: Zefram <A.Main@xxxxxxxxxxxxxxxxx>
- To: hzoli@xxxxxxxxxx (Zoltan Hidvegi)
- Subject: Re: Distribution terms
- Date: Tue, 27 Aug 1996 21:20:42 +0100 (BST)
- Cc: schaefer@xxxxxxx, gjb@xxxxxxxxxxxxxxx, zsh-workers@xxxxxxxxxxxxxxx
- In-reply-to: <199608271925.VAA08321@xxxxxxxxxxxxxxxxx> from "Zoltan Hidvegi" at Aug 27, 96 09:25:28 pm
> 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
> 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
> 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.
Messages sorted by: