On Wed, 26 Apr 2006 09:21:25 +0200 Casper.Dik at Sun.COM wrote:
> What other tools use these libraries?
> (If it's only ksh, I am of the opinion that they need to be
> statically linked to ksh and not shipped as libraries; if they're
> used bby many other tools then, of course, not)
> We don't want to get into some "Mozilla" DLL craze.
> (If it isn't shared, it shouldn't be a shared library; and if it is shared,
> it shouldn't be 40 libraries)
libcmd implements section (1) commands
the entry point for foo(1) is
int b_foo(int argc, char** argv, void* handle);
where handle is used by ksh
the same code implements the ksh builtin and the standalone commands
ksh calls b_*() directly
the standalone commands dynamically link to libcmd with the thinest of main's:
int main(int argc, char** argv) { return b_foo(argc, argv, 0); }
to avoid LD_* nightmares at system startup ksh by default statically links
with -lshell -lcmd -last
however, users wishing to program their own builtins will need at least
-lshell -last dlls and would probably be the same group expecting a -lcmd dll
the .paths file (found on $PATH), already mentioned by dgk on this thread,
provides a way to hook in a builtin dll (like -lcmd) as if it were a bin
directory containing a command for each b_*() entry in the dll
-lcmd and similar user-supplied builtin libraries will become
popular and addictive for script applications that can realize the
10x speedup of builtins over fork/exec/spawn
the upshot is that an appreciable performance boost may be as simple
as "add this dir to your PATH" where "this dir" contains a properly
crafted .paths file and associated libraries
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
