|
The SAM distribution is divided into "modules". I chose that
word, because I didn't want to call them "packages". Like
Slackware packages, they can be installed separately, and I used to
distribute them that way. Recently I decided it is better to
distribute them together, but as they are disinct one from
another, it is helpful for understanding to be aware of them.
Incidentally, I don't call them "packages", because they don't install
like Slackware packages, and I wanted to avoid confusion.
SAM has five modules, and it is from them that the long name for SAM,
SAM Kernel and Application, derives. The modules of SAM
are:
example
kernel
main
pkg_tool
tool
SAM is pretty clever. It's purpose is to give you a convenient
and powerful, stack-based, way to manage your executables/functions and
associated documentation. It does this by manipulating the
environment, but it starts by putting certain key executables/functions
(from module kernel) in the PATH/environment.
You do that by running a script which which opens a Bash shell specific
to SAM.
Once that is done, then you have new resources (functions,
executables and documentation) available within SAM's shell.
These can be used from the command line, but also from scripts.
This makes SAM a powerful scripting tool. SAM is, in fact,
valuable to me personally, which is why I use it daily and frequently
write new scripts and function definitions which reference SAM-based
functions and executables.
When I write these SAM-based scripts and functions I want to put
them, and their associated documentation, someplace that is useful to
me. So I have to decide whether or not to include them as part of
SAM. When I do include them I put them mostly in module
example, but sometimes in module
pkg_tool or tool. Often the
SAM-based scripts and functions I write end up somewhere else
completely--not in SAM or even near it.
This is the nature of SAM--where ever you put your tools, that's
where they live--tool sets live in directories
I put example scripts in module example to
illustrate this. They are more than just examples, however, many
of them are currently maintained and quite useful. Others, I must
note, are old and of questionable use, but they still serve as
examples. Perhaps some cleaning up is in order, but this illustrates
the way in which SAM gives life to your tools. I use SAM
daily. It is an essential part of my use of Slackware Linux, and
I frequently write new scripts and function definitions which reference
SAM-based functions and executables.
Usually I do this simply to meet my needs. I may have a task
that could be improved by a script or function or a collection of
scripts and functions. With SAM it is easy to organize and
document them. The tools come to life and become useful.
So that is what the modules are about. They are tool sets in
directories, and except for kernel, they are just like
any other collection of tools that reference SAM-based functions and
executables. I made them modules of SAM, because I judged them to
have a special relationship to SAM, but that is pretty much
arbitrary. Really they are just collections of tools.
kernel is also a collection of tools, but they are
special tools. This is where I put the tools which give SAM its
spark of life. Commands bound,
hello, bye, push,
pop, sam_core,
sam_shel, sam_view live here.
These are Bash scripts and functions. This dir is also home to
three essential C executables: exp_filt.exe,
mk_unset.exe and set_filt.exe.
I should mention main briefly. By use of
symlinks it is made to appear to contain the other modules. It
also contains two half-special tools which straddle the line
between kernel and application: go/sam and
go/sam1. These are responsible for some of the
nitty-gritty details that make SAM work.
|