From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16918 invoked from network); 9 Sep 2000 23:16:33 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Sep 2000 23:16:33 -0000 Received: (qmail 12006 invoked by alias); 9 Sep 2000 23:16:11 -0000 Mailing-List: contact zsh-users-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 3415 Received: (qmail 11999 invoked from network); 9 Sep 2000 23:16:09 -0000 From: "Bart Schaefer" Message-Id: <1000909231542.ZM3934@candle.brasslantern.com> Date: Sat, 9 Sep 2000 23:15:42 +0000 In-Reply-To: <20000909154409.A20039@rom.oit.gatech.edu> Comments: In reply to Will Day "Re: two sets of modules under /usr/local/lib/zsh ?" (Sep 9, 3:44pm) References: <20000908234850.A16212@rom.oit.gatech.edu> <1000909160549.ZM139@candle.brasslantern.com> <20000909154409.A20039@rom.oit.gatech.edu> X-Mailer: Z-Mail (5.0.0 30July97) To: zsh-users@sunsite.auc.dk, Will Day Subject: Re: two sets of modules under /usr/local/lib/zsh ? MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii (Moved from zsh-workers to zsh-users, as most of the developers are likely to know this already, but it may be of interest to users). Quick recap: In 3.1.6-pws-13, hierarchical module naming was introduced, which means that when you install 3.1.9 you appear to have two of each of the modules, one under .../zsh/3.1.9/ and one under .../zsh/3.1.9/zsh/. The modules directly under .../zsh/3.1.9/ were eliminated in 3.1.9-dev-5, so you won't see "two sets" any more when 4.0 is released. This led to a question about how one is supposed to load the modules. On Sep 9, 3:44pm, Will Day wrote: } } Well, in my case, I had MODULE_PATH already being set in my startup files, } and so I just added the 'zsh' subdir to the path. Of course, reading your } subsequent mail, this is apparently the wrong thing to do. Yes, that's the wrong thing to do. The "alias modules" are just dummy files that load nothing, used to cause a dependency on the real modules in the zsh/ subdirectory. So in 3.1.7 through 3.1.9, when you say (with the default MODULE_PATH) `zmodload stat' you end up loading two modules, `zsh/stat' which is the one you really want, plus the dummy `stat' module that depends upon zsh/stat. The "real" modules all have dependency information expressed as the hierarchical name (e.g. zsh/compctl depends on zsh/complete), so if you load by the base name with a modified MODULE_PATH, zsh will not do the right thing with the dependencies. (For zsh-users: The "subsequent mail" mentioned above suggests that we try to do something about this.) } Also, I'm not quite clear on why the MODULE_PATH isn't to be used like a } shell PATH, listing all the directories wherein modules may be found. Well ... that *is* how it's used, really ... there's nothing that says you *can't* have a module at the top of the hierarchy (like the alias modules are). But when the (separate) decision to have hierarchically- named modules was made, the implementation chosen was to reflect the hierarchical name of the module as actual filesystem hierarchy, which meant it had to be *relative* to the directories in the MODULE_PATH. The thing about both PATH and MODULE_PATH is that they imply an ordering -- if identically-named commands or modules appear in two places, only the first one found is used -- which the hierarchical naming scheme does not; that is, you're *supposed* to be able to have both a local/files and a zsh/files module, and use either of them (or both if they don't supply conflicting functionality). -- Bart Schaefer Brass Lantern Enterprises http://www.well.com/user/barts http://www.brasslantern.com Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net