Subject: Re: [ksh93-integration-discuss] Solaris packaging of ksh93 components
(libast, libcmd, libdll, libshell)
--------
There are pros and cons to having libast, libcmd, and libshell as separate
shared libraries rather than statically linking libshell to libast and libcmd.
The primary benefit of keeping each as shared libraries is
that applications would be able to use the services provide
by libast and libcmd. One of the components of libast is sfio, which
is an I/O library similar to stdio, but more consistent,
more extensible, and typically faster than stdio. Programs
like perl have been configured to be able to use sfio for
better performance. sfio provides a <stdio.h> header file that
allows it to be used with the stdio interface.
sfio uses memory mapping for input by default and dynamic buffer sizing
for random access. It supports strings and files symetrically.
There are other components to libast that are equally useful.
The cdt component provides much of the functionality of
the C++ standard template library in C by providing
lists, queues, stacks, trees and other dictionary container
classes.
The vmalloc component provides a generalization of malloc()
that can be used to manage multiple regions of memory
using different algorithms that are suited to the type
of use.
libshell, which provides the shell functionality
relies heavily on each of these components. Because
it uses sfio, and sfio provides a stdio interface as well,
extensions written for libshell can use either sfio or stdio.
ksh93 has the ability to load shared libraries at run time
to extend the functionality of the shell by adding built-ins
and/or other extensions like tksh (tk+ksh), and dtksh (Xlib+ksh).
In addition libshell can be embedded into other applications
to provide shell functionality.
If libast is statically linked, then extensions to ksh can
only use functions from libast that the libshell has statically
linked in unless the extension also statically links with libast.
Libcmd provides POSIX conforming implemenations of many
common commands including all of the following:
basename.c
cat.c
chgrp.c
chmod.c
chown.c
cmp.c
comm.c
cp.c
cut.c
date.c
dirname.c
expr.c
fmt.c
fold.c
getconf.c
head.c
id.c
join.c
ln.c
logname.c
mkdir.c
mkfifo.c
mv.c
paste.c
pathchk.c
rev.c
rm.c
rmdir.c
stty.c
tail.c
tee.c
tty.c
uname.c
uniq.c
wc.c
The commands all support GNU style long options and have GNU extensions.
They all generate their own man page with
command --man
However, since any of these can be selected as built-ins, they can
run much faster. For, example, a loop like
for i in $(...)
do chmod "$i"
done
could run 50 times faster than the non-builtin version.
The shell can be configured to associate each of these with a
directory so that the built-in will only be run with the PATH
search would search that directory. This way, if say wc is
a builtin version of /usr/bin/wc, then if the user has their
PATH set so that another wc would come first, the libcmd
version will not be used.
One other side benefit of having these as built-ins is that
there is not ARG_MAX limit since exec*() is not used.
With our i-paq implementation, were replaced all of these commands
with a single command (hard linked by name) that just invoked
the corresponding builtin. The result was the the size for ksh,
and these commands + libcmd + libshell + libast took less space
then these commands did.
If libshell, libcmd, and libast are separate, they will
all need to be on the boot disk assuming that ksh
will need to run at boot time.
Note that if you want to use create shell extensions, you will
need <shell.h> and <shell.h> uses many of the other ast headers.
It would be best if you put all the ast headers in /usr/include/ast.
This way none will conflict with headers in /usr/include.
Programs that want to use the libast stdio, would need to specify
-I/usr/include/ast
and link with -last.
David Korn
dgk at research.att.com
