Hits since 2022-03-19 02:46:06:

Rosevear Software

The Modules of SAM:

The Modules of SAM

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:

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.

© Joseph Rosevear
  |   Source touched: 2022-03-20 16:02:35   |