Darren J Moffat wrote:
> 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 ?
No, the idea is to have a common location with DNS-like hiearcy for
shell functions and allow that we may have a common directory for shell
functions in the POSIX shell syntax - which could then be shared by
multiple shell interpreters. For example we could have:
/usr/lib/shell/sh/org/opensolaris/util/fileattr/getfilesize which can be
shared between ksh93, bash and zsh. Another example is the "shell
curses" package which could exists under:
/usr/lib/shell/ksh/com/ibm/term/shellcurses # for ksh93 and
/usr/lib/shell/zsh/com/ibm/term/shellcurses # for zsh
One imporant item I forgot (which came up during yesterday's IRC
discussion) is that we try to allow access to the modules without using
abolute paths, e.g. we could define something ${.sh.funclib} which
points to /usr/lib/shell/ksh/ and a shell could then use
FPATH+="${.sh.funclib}/com/ibm/term/shellcurses" to access the shell
curses packages or
FPATH+="${.sh.funclib}../sh/org/opensolaris/util/fileattr/getfilesize"
to access the "util/fileattr/getfilesize" function... or
FPATH+=:${.sh.funclib}../sh/org/opensolaris/util/fileattr/* to access
all modules in sh/org/opensolaris/util/fileattr/*
> 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/ ?
Please change that to /usr/lib/ksh/ - the (19)93 part is a version
number.
> 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.
I doubt that. At least for the curses stuff we have two parallel
implementations (ksh, zsh).
> Last but not least what is a shell ? would /usr/lib/shell/python be
> allowed ?
The answer is "yes" if python can deal with the POSIX shell syntax...
and "no" if it can't hand this syntax.
----
Bye,
Roland
--
__ . . __
(o.\ \/ /.o) roland.mainz at nrubsig.org
\__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer
/O /==\ O\ TEL +49 641 7950090
(;O/ \/ \O;)
