two sets of modules under /usr/local/lib/zsh ?

two sets of modules under /usr/local/lib/zsh ?

[Will Day]

[-- Attachment #1: Type: text/plain, Size: 2361 bytes --]

Okay, I haven't been keeping up with the list since 3.1.6, so this may be a
stupid question, but why are there two sets of modules under
/usr/local/lib/zsh?  There seems to be a set under 3.1.9, and then another,
larger, set under 3.1.9/zsh.

Looking through the NEWS and the mailing list archives, I see the modules
were moved from the version dir to the zsh subdir, and the ones in the top
directory are apparently called "alias modules".  However, what really
baffles me, is that they all appear to be the same file:

   % cd /usr/local/zsh/3.1.9
   % sum *.so
   33949     5 cap.so
   33949     5 clone.so
   33949     5 compctl.so
   33949     5 complete.so
   ...

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, and (b) if
say I do want them, could they not instead be just symlinks to the
respective module under the zsh subdir?  Ie:

   % cd /usr/local/zsh/3.1.9
   % ls -l *.so
   lrwxrwxrwx   1 root   other   10 Sep  8 23:39 cap.so -> zsh/cap.so
   lrwxrwxrwx   1 root   other   10 Sep  8 23:39 clone.so -> zsh/clone.so
   lrwxrwxrwx   1 root   other   10 Sep  8 23:39 compctl.so -> zsh/compctl.so
   lrwxrwxrwx   1 root   other   10 Sep  8 23:39 complete.so -> zsh/complete.so

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?

I probably wouldn't ever notice or care, except that I'm building a Solaris
pkg to install across all our machines, and the prototype file gets a bit
confusing with two of every module in there.  If I can make them symlinks,
or hardlinks, it'll make it all cleaner and easier to deal with. :)

Also, I guess I'm a little curious about it all, since the new path:
   /usr/local/zsh/3.1.9/zsh/cap.so

seems a little unnecessarily redundant, with two "zsh"'s in there.

-- 
Will Day     <PGP mail preferred>     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

[-- Attachment #2: Type: application/pgp-signature, Size: 360 bytes --]

Re: two sets of modules under /usr/local/lib/zsh ?

[Zefram]

Will Day 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.

>say I do want them, could they not instead be just symlinks to the
>respective module under the zsh subdir?  Ie:
...
>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).

-zefram

Re: two sets of modules under /usr/local/lib/zsh ?

[Bart Schaefer]

On Sep 8, 11:48pm, Will Day 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

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.
You'll eventually need to do that anyway, though, because as Zefram said
the alias module files went away in 3.1.9-dev-5, replaced by an internal
aliasing mechanism ("zmodload -A").

If you mean "I never used the zmodload command" then you don't need them.

} Also, I guess I'm a little curious about it all, since the new path:
}    /usr/local/zsh/3.1.9/zsh/cap.so
} 
} seems a little unnecessarily redundant, with two "zsh"'s in there.

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/<whatever>/zsh/<version>/.


-- 
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   

Re: two sets of modules under /usr/local/lib/zsh ?

[Will Day]

[-- Attachment #1: Type: text/plain, Size: 2763 bytes --]

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/<whatever>/zsh/<version>/.

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.

-- 
Will Day     <PGP mail preferred>     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

[-- Attachment #2: Type: application/pgp-signature, Size: 360 bytes --]