From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: zsh-users@sunsite.auc.dk, Will Day <willday@rom.oit.gatech.edu>
Subject: Re: two sets of modules under /usr/local/lib/zsh ?
Date: Sat, 9 Sep 2000 23:15:42 +0000 [thread overview]
Message-ID: <1000909231542.ZM3934@candle.brasslantern.com> (raw)
In-Reply-To: <20000909154409.A20039@rom.oit.gatech.edu>
(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
parent reply other threads:[~2000-09-09 23:16 UTC|newest]
Thread overview: expand[flat|nested] mbox.gz Atom feed
[parent not found: <20000909154409.A20039@rom.oit.gatech.edu>]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1000909231542.ZM3934@candle.brasslantern.com \
--to=schaefer@candle.brasslantern.com \
--cc=willday@rom.oit.gatech.edu \
--cc=zsh-users@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).