James Carlson wrote: > Darren J Moffat writes: >> How does /usr/lib/shell usage compare with the existing: >> >> /usr/share/zsh/<version>/functions/ >> /usr/share/zsh/<version>/scripts/ >> /usr/share/zsh/site-functions/ > > All of the files under /usr/share/zsh are shell scripts and > architecture-independent. They could (at least in principle) be > shared between architectures. > >> Does the creation of /usr/lib/shell imply that those things that are >> currently in /usr/share/zsh should move to /usr/lib/shell/zsh ? > > Roland has already said that there'll be architecture-dependent > objects in the /usr/lib/shell directory. That alone makes it > inappropriate for /usr/share.
I think you missed the point I was trying to make it wasn't a /usr/share vs /usr/lib distinction but the fact that there is already a system wide place for zsh "extensions/plugins/whatever" yet this case appears to be suggesting that /usr/lib/shell/zsh would be that place. Zsh has already staked out some of its ground. Similarly we already have /usr/lib/python. On the other hand we have /usr/perl and /usr/ruby/ and both /usr/java and /usr/share/lib/java :-( Or let me ask this another way. Given that all the shells are upstream from OpenSolaris and that they may or may not already have some "system wide" area what is it that we are actually trying to do with /usr/lib/shell ? Is /usr/lib/shell really /usr/lib/ksh ? What architectural value is /usr/lib/shell/ adding what are the rules for putting something in there versus the shells own system wide area? Is it really /usr/lib/shell or /usr/lib/ksh93/ ? Until we have some real examples or a real need I don't see that this is generic to *all* shells and is more likely specific to some class of shells maybe which might be just ksh93. Last but not least what is a shell ? would /usr/lib/shell/python be allowed ? -- Darren J Moffat
