One library, SAM.tool, comes pre-installed. The user may
install as many additional libraries as desired. These may come
from me or from anyone. You may make your own.
It is important to understand that libraries are a convenience, and
that is all. They are abstractions which provide a consistent
interface to menus.
SAM.tool, for example, is represented by the library
$lib/tool. The commands of the library can
be added to the current command set by:
bound $lib/tool
and by variations on the above. You may do this, and you
should just to see what happens, although it is unlikely to have any
real effect* if it is already referenced in the corresponding
init file.
*Let's say that it is already referenced as I described,
and you try it anyway. You can observe this unlikely effect on
PATH by following up with the use of shoparts
PATH. At most you may see a change in the order of
directories in PATH.
In addition to executables, the command set may also contain
functions. If the set of directories from which your qualified
functions are derived contains functions with names that are not
unique--generally not a good idea--then this sort of maneuver may
change which of them are available in the command set by changing
the order in they are defined.
Let me explain a little. SAM can be started by
begin in the root of SAM or by a symlink in a
dual directory. In either case the default
bprofile,
init and
lib are the ones in the corresponding
directory (either the root of SAM or the
dual directory).
SAM refers to
bprofile,
init, and
lib using
$bprofile,
$init, and
$lib and thus
makes sense of this.
To configure SAM so that a library is automatically added to the
current commmand set when SAM is started, simply reference it in the
corresponding init file. The
init in the distribution comes pre-configured with a
reference to $lib/tool:
echo : $lib/tool final
To learn more about how SAM supports the use of libraries and about
the SAM.tool library, please read the GUIDE which is included in the
distribution.