From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (list@euclid.skiles.gatech.edu [130.207.146.50]) by coral.primenet.com.au (8.7.5/8.7.3) with ESMTP id GAA01967 for ; Wed, 28 Aug 1996 06:21:33 +1000 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id QAA27216; Tue, 27 Aug 1996 16:22:31 -0400 (EDT) Resent-Date: Tue, 27 Aug 1996 16:22:31 -0400 (EDT) From: Zefram Message-Id: <6222.199608272020@stone.dcs.warwick.ac.uk> Subject: Re: Distribution terms To: hzoli@cs.elte.hu (Zoltan Hidvegi) Date: Tue, 27 Aug 1996 21:20:42 +0100 (BST) Cc: schaefer@nbn.com, gjb@moa.cs.duke.edu, zsh-workers@math.gatech.edu In-Reply-To: <199608271925.VAA08321@bolyai.cs.elte.hu> from "Zoltan Hidvegi" at Aug 27, 96 09:25:28 pm X-Loop: zefram@dcs.warwick.ac.uk X-Stardate: [-31]8029.23 X-US-Congress: Moronic fuckers MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"rIzIJ3.0.Af6.6ar8o"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/2085 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu > 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