I think I can safely say that SAM is going in a new
direction. I have had over the last couple of years two
opportunities to meaningfully share SAM with other *nix
users.
This was great for me and for SAM, as it gave me some
insight. I saw that SAM has grown into a tangled, but useful,
mess. Therefore I have begun a process of cleaning up.
The SAM distribution has a kernel and an application. It is
mostly the application that needs cleaning up, as it contains a lot
of example code that, for various reasons, is not appropriate for
inclusion in SAM--junk, in a word.
Some of this junk is useful code. Because SAM is a great
framework for writing code to solve problems, I had filled it up
with lots of code that I had written for my own use. I did this
thinking that, as it was useful to me, it might be useful to others
also. And I did it from laziness. It was easier to put the
code in my example menu than it was to find a convenient but
separate place to stage the code.
Now, seeing the error in my ways, I have designed exactly that: a
convenient, but separate place to stage my code. The solution
I found was simple. SAM code lives in menus, and the menus
menus are just directories. Therefore I found that I could
stage my code in directories which are separate from SAM.
Here's an example that shows what I mean:
Before, I did this (at the SAM command line) to run tool
"prep" that mounts my encrypted drive:
Now I do this:
It is admittedly more to type, but it works and allows me to
host prep outside of the SAM distribution.
The above example was about application junk. SAM
also has special files and directories (that serve an executive
role) that live in the root of the installed distribution; I have
found that junk of another kind (executive junk) accumulates
here. This problem is odd. I don't need to edit the
files and directories here, but I do need to make copies of
them, then edit the copies. I do this to tailor SAM for my own
use.
Previously, I put the modified copies of these files and
directories also in the root of the installed distribution, giving
them different names. Then when making the distribution I had
the annoying task of editing code that excluded the stuff that I
didn't want in the distribution. This made releasing SAM slow
and difficult.
Now I do things differently. First here is some
background: Some of the files of the root of the distribution
begin with the letter "b" and are invoked by the user to start
SAM. I call these b-files. More than one b-file
is needed, because they start SAM in different ways. For
example begin starts SAM normally, and
bree re-starts SAM as root, keeping the menu and
current directory the same, a SAM session that is already running as
non-root.
I have found a way to start SAM by invoking either a
b-file in the root of the installed distribution or,
alternately, invoking a b-file in a custom dir elsewhere that
contains symlinks to some of the stuff in the root of the installed
distribution. In other words, I can have my cake and eat it
too!
The above solution is not hard to implement and it gives me a
simple way to keep the junk out of the root of the SAM
distribution.
I was inspired to make these changes to reduce the junk in SAM by
the sharing of SAM as I described above. Receiving well
intentioned feedback helped me to see more clearly what I needed to
do. The work is ongoing, but hopefully it will result in a
simplified SAM that is easier to document, use and understand, yet
still contains a good collection of useful example applications.
I will not name the individuals I spoke of, as I did not receive
their permission, but I will say that I found them in these two
locations:
- The Usenet group called "alt.os.linux.slackware".
- The Facebook group at
https://www.facebook.com/groups/unixshell/