On Fri, 22 Sep 2006 10:02:54 -0400 James Carlson wrote:
> A better alternative might be to look at the places scanned. It
> doesn't seem to make sense to me that 'builtin -f' would resolve
> against /usr/lib, at least first in the list. I sure don't want
> 'builtin -f ipmp' to load the IPMP library into the shell; there's
> nothing useful there.
> Why wouldn't this scan a ksh93-specific location first, such as a
> /usr/lib/ksh93/ directory? You could have your own libcmd.so{,.1}
> buried in there, encourage others to deliver plugin libraries to that
> separate directory, and there'd be no conflict.
the simple answer is "yes"
ast -ldll does the plugin mapping from
"foo" => "<some-path>/<some-prefix>foo<some-suffix>"
as it turns out ast plugins can be associated with an application or
classification name that essentially adds another dir level
"foo" => "<some-path>/<application>/<some-prefix>foo<some-suffix>"
so, e.g., open source ast already has "pax" plugins (for just about
any archive format, at least for read), "vcodex" plugins for compression
and transformation
the upshot is that, on solaris, ksh first looks for plugins for the
"ksh" application, so the "ksh" "cmd" plugin, with solaris physical name
"libcmd.so[optional-version]", could reside in
../lib/ksh/libcmd.so[optional-version]
somewhere on $PATH and
builtin -f cmd
will find the first one with the newest version (or with specific version
constraints depending on how ksh coded the load plugin call)
ast packages containing ksh and -lcmd do not by default install -lcmd
in a ksh subdir (it may in a future release), but dgk has a few plugins
planned that will be installed there
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
