From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15663 invoked from network); 9 Sep 2000 19:44:26 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Sep 2000 19:44:26 -0000 Received: (qmail 24231 invoked by alias); 9 Sep 2000 19:44:15 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12785 Received: (qmail 24217 invoked from network); 9 Sep 2000 19:44:10 -0000 Date: Sat, 9 Sep 2000 15:44:09 -0400 From: Will Day To: zsh-workers@sunsite.auc.dk Subject: Re: two sets of modules under /usr/local/lib/zsh ? Message-ID: <20000909154409.A20039@rom.oit.gatech.edu> Reply-To: Will Day References: <20000908234850.A16212@rom.oit.gatech.edu> <1000909160549.ZM139@candle.brasslantern.com> <20000908234850.A16212@rom.oit.gatech.edu> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="EVF5PPMfhYS0aIcm"; micalg=pgp-md5; protocol="application/pgp-signature" User-Agent: Mutt/1.1.2i In-Reply-To: ; from zefram@fysh.org on Sat, Sep 09, 2000 at 10:26:25AM +0100 X-no-archive: yes --EVF5PPMfhYS0aIcm Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable A short time ago, at a computer terminal far, far away, Zefram wrote: >>And I guess I'm wondering, if these are only for backwards compatibility, >>(a) do I need them, if I never used paths for modules anywhere, > >No. In fact, they've been removed in newer versions. > >>Or, at the very least, have the module files in that toplevel dir all >>hardlinked together, since they all appear to be the same file anyway. >>Or am I missing something? > >Yes, either of these will work, on ELF systems. Some dynamic loading >systems that zsh supports have requirements that mean that all module >files have to be different (effectively, the module needs to know its >own name). Thanks, that definitely helps. A short time ago, at a computer terminal far, far away, Bart Schaefer wrote: >What do you mean by "I never used paths for modules anywhere" ? > >If you mean "I used modules, but never by their paths" then if you don't >have the alias modules you'll have to change your startup files or any >other places where you used modules, to use the zsh/modulename form. > >If you mean "I never used the zmodload command" then you don't need them. 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. >It's an attempt to be forward-looking, so that other modules that are >not part of the zsh "package" can be distrubuted under separate module >hierarchies, but all live under /usr//zsh//. Ah, okay, well I can certainly see having separate directories for distributed modules vs local modules. I guess the "zsh" subdir name just seems non-intuitive; something like "main" or "dist" or "builtin" or "standard" or something to indicate that these are modules that _come with_ zsh would be more descriptive. Calling it "zsh" when they're _all_ modules for zsh (even the ones installed locally) is somewhat confusing. :) 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. Although, if it's because dependencies are resolved by load-name, rather than an internal name, then I can see how that would cause problems, as you describe in your other email. --=20 Will Day OIT / O&E / Technical Support willday@rom.oit.gatech.edu Georgia Tech, Atlanta 30332-0715 -> Opinions expressed are mine alone and do not reflect OIT policy <- Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin, Pennsylvania Assembly, Nov. 11, 1755 --EVF5PPMfhYS0aIcm Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.2 (Solaris) Comment: http://rom.oit.gatech.edu/~willday/pubkey.asc iQCVAwUBObqTCBDHlOdPw2ZdAQFsiQP9F80CyDZXEflqz9PnGvXQ1PsmlSYFCuF7 cedqHJRuJWa/1ndFMcPoSgQC3osM+DlIhoVFBtpRqobOjz4XrLWnrfHiiNp7OXrA HHv7/KqLGvh+vBeS0KS/5HaVzftzgoQy2+95tvKAdl/APP4XNO2pG5+iBUAHQ1wN eahO0NOHUqM= =RMjc -----END PGP SIGNATURE----- --EVF5PPMfhYS0aIcm--