From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8406 invoked from network); 11 Dec 1998 17:50:03 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 11 Dec 1998 17:50:03 -0000 Received: (from list@localhost) by math.gatech.edu (8.9.1/8.9.1) id MAA16321; Fri, 11 Dec 1998 12:42:38 -0500 (EST) Resent-Date: Fri, 11 Dec 1998 12:42:38 -0500 (EST) From: "Bart Schaefer" Message-Id: <981211094053.ZM21039@candle.brasslantern.com> Date: Fri, 11 Dec 1998 09:40:53 -0800 In-Reply-To: <199812111416.PAA03428@beta.informatik.hu-berlin.de> Comments: In reply to Sven Wischnowsky "Re: wrapper functions in modules" (Dec 11, 3:16pm) References: <199812111416.PAA03428@beta.informatik.hu-berlin.de> X-Mailer: Z-Mail (4.0b.820 20aug96) To: Sven Wischnowsky , zsh-workers@math.gatech.edu Subject: Re: wrapper functions in modules MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"Xo6yA.0.y-3.EcLSs"@math> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/4755 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu On Dec 11, 3:16pm, Sven Wischnowsky wrote: } Subject: Re: wrapper functions in modules } } [...] my first idea was to let modules register only one function } which would have to call back the execution code [...] } This would solve the call stack problems you mentioned. Also, writing } wrappers would be easier in modules since you can use local variables, } static local variables for number-of-calls and so on... This would indeed be an improvement. An interesting side-effect is that it would permit a module to decide not to run the shell function at all; it could instead branch off into any code it liked. That in turn probably makes modules even more dangerous than before, from a run-time perspective. An innoccuous module placed in root's module path could suddenly have someone else driving the shell. It might even be a good idea to have zsh refuse to dynamically load modules when EUID==0, or at least refuse to auto-load them. } About the problems with unloading: I would vote for completely } disallowing to unload a module if a wrapper is active for it. } This is relatively easy to keep track of and seems to be the savest (Safest.) This still isn't quite good enough -- you can't unload modules upon which other modules depend, so if X has a wrapper and depends on Y, you can't unload Y even though Y has no wrapper. This probably means you end up refusing to unload any modules at all whenever there are any wrappers at all, which may be problematic. } the question is: how often does one want to unload modules in shell } functions? I could envision someone wanting to write a pair of functions, one that installs several related modules and another that uninstalls them again. } Finally about the order in which installed wrappers are to be called: } looking at load_module() it should be enough to build the wrappers } list by appending new definitions to the end. Yes, as I said, if the only constraint is module dependencies this will work fine. Side note to Phil Pennock: If we get this worked out, then an emulator module for ksh would be the perfect way to fudge WORDCHARS and various keybindings for later restoration ... -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com