Hello Slackers,

What is a wedge? I'm looking for a term to describe something that I use.

It is code that I wrote, and I'm wondering if it has a category or if it
is something new.

I would like to call it a wedge, because I found online a reference to
code for the Commodore 64 that was called by that name. I believe it was
code that augmented the existing Commodore 64 command set. Anyway, that
is how I mean to use the term, except that I am augmenting the existing
Slackware command set.

I'm sorry if this is drifting into the gray zone of the esoteric. Maybe
it will help if I tell you how this got started:

I was an engineer working for General Dynamics Corporation, Space Systems
Division in San Diego. I was in the Advanced Structures Analysis group,
and I was responsible for creating/maintaining an interface to a
collection of analysis software. This was in about 1986, and we were
using a variety of computers that included networked *nix machines. I
think they were called Apollo Workstations, and they ran a Unix-like
system called Domain.

To make a long story short: I have system on my PC which I call SAM. It
is a descendant of the Structural Analysis Menu that I wrote years
previous. It is a collection of Bash scripts and functions with a few C
language executables thrown in for good measure.

So why does this matter? (Forgive me for taking so long to get to the
point.) As a Slackware Linux user I make extensive use of the command
line. I don't know how *you* manage the awesome complexity of the
command line, but I have found it useful to write a set of commands that
augment the existing Slackware command set. This wouldn't be
particularly interesting except that I did it in a novel way.

The traditional way of managing such a set of commands is to dump them
in /usr/local/bin or some other dir which is in the PATH. But what if
some of the commands actively managed the current environment including
the PATH? Then any dir could contain your new commands.

That is what I have done. I have "gone down the rabbit hole". SAM is
useful. I use it to create interactive collections of executables of all
kinds--mainly bash scripts and functions, but also C language executables
and Python scripts. (But any exectuable could be included.)

So I ask you--what is a wedge? Is SAM a wedge? Is there a better name
for it.

-Joe

On Thu, 23 Mar 2023 00:06:14 +0000, Joseph Rosevear wrote:

> But what if some of the commands actively managed the current
> environment including the PATH?

> That is what I have done.

The problem with the environment variables like PATH is that it can be
inherited by child processes, but a child process cannot alter the
environment of a parent process.

To change some environment variable like PATH from your shell, you cannot
call a new process to do that for you. Instead your shell has to change
its environment, possibly by reading the output of some other process or
possibly by running some commands without forking a new process (like
sourcing another script).

There are existing tools to do things like this, one such example is
environment modules available at https://modules.readthedocs.io/en/latest/

These tools usually define some kind of shell alias to alter the
environment variable. The alias will look differently depending upon what
shell is used.

regards Henrik

On 23/03/2023 10:36, Joseph Rosevear wrote:
> Hello Slackers,
>
> What is a wedge? I'm looking for a term to describe something that I use.
>
> It is code that I wrote, and I'm wondering if it has a category or if it
> is something new.
>
> I would like to call it a wedge, because I found online a reference to
> code for the Commodore 64 that was called by that name. I believe it was
> code that augmented the existing Commodore 64 command set. Anyway, that
> is how I mean to use the term, except that I am augmenting the existing
> Slackware command set.

<SNIP>
The C=64 Wedge is described at https://en.wikipedia.org/wiki/DOS_Wedge;
to me it sounds like the old MS-DOS TSR programs like Sidekick
https://en.wikipedia.org/wiki/Borland_Sidekick which would intercept
certain key combinations and perform some action accordingly.

On Thu, 23 Mar 2023 06:55:17 -0000 (UTC), Henrik Carlqvist wrote:

> On Thu, 23 Mar 2023 00:06:14 +0000, Joseph Rosevear wrote:
>
>> But what if some of the commands actively managed the current
>> environment including the PATH?
>
>> That is what I have done.
>
> The problem with the environment variables like PATH is that it can be
> inherited by child processes, but a child process cannot alter the
> environment of a parent process.
>
> To change some environment variable like PATH from your shell, you
> cannot call a new process to do that for you. Instead your shell has to
> change its environment, possibly by reading the output of some other
> process or possibly by running some commands without forking a new
> process (like sourcing another script).
>
> There are existing tools to do things like this, one such example is
> environment modules available at
> https://modules.readthedocs.io/en/latest/
>
> These tools usually define some kind of shell alias to alter the
> environment variable. The alias will look differently depending upon
> what shell is used.
>
> regards Henrik

Hello Henrik,

You wrote that "a child process cannot alter the environment of a parent
process". That is true.

But that is not what SAM does. Instead it: pushes the current
environment to a stack for reuse later, changes the PATH in the current
process, makes a corresponding change to the prompt, and runs hash.
Additionally it unsets functions and defines new functions to correspond
to the change in menu.

In this way it simulates the making of a new shell without actually doing
so.

You mentioned sourcing a script. SAM has a special function, dofun. Its
defining script is sourced and then dofun is exported. It becomes, in
this way, the parent of all the other functions.

In response to your question, I spent a few hours (just now) making
another SAM video for my website. It shows the use of SAM to change the
PATH. You can view it here:

https://joeslife.org/projects/RS/pictures/flash/sam_demo2_f

I went to the website you named--thank you for that. It shows that I'm
not alone in my work, after all.

-Joe

On Thu, 23 Mar 2023 19:04:15 +1030, David Robley wrote:

> On 23/03/2023 10:36, Joseph Rosevear wrote:
>> Hello Slackers,
>>
>> What is a wedge? I'm looking for a term to describe something that I
>> use.
>>
>> It is code that I wrote, and I'm wondering if it has a category or if
>> it is something new.
>>
>> I would like to call it a wedge, because I found online a reference to
>> code for the Commodore 64 that was called by that name. I believe it
>> was code that augmented the existing Commodore 64 command set. Anyway,
>> that is how I mean to use the term, except that I am augmenting the
>> existing Slackware command set.
>
> <SNIP>
> The C=64 Wedge is described at https://en.wikipedia.org/wiki/DOS_Wedge;
> to me it sounds like the old MS-DOS TSR programs like Sidekick
> https://en.wikipedia.org/wiki/Borland_Sidekick which would intercept
> certain key combinations and perform some action accordingly.

Thank you David,

Its funny that I had forgotten about the Wikipedia article about the C=64
Wedge. I actually have a link to it in my (RosevearSoftware) website
here:

https://rosevearsoftware.com/products/sam/what/wedge

Thank you for jogging my memory. It seems that two websites is too many
to manage.

And thank you also for mentioning Borland Sidekick. Yes, it does seem to
belong in the same category.

-Joe

On Thu, 23 Mar 2023 23:07:34 +0000, Joseph Rosevear wrote:
> You mentioned sourcing a script. SAM has a special function, dofun.
> Its defining script is sourced and then dofun is exported. It becomes,
> in this way, the parent of all the other functions.

Yes, this works with bash and I think that also other module
implemantations usually also do so with bash. With other shells like tcsh
they might instead use something like alias and eval.
> In response to your question, I spent a few hours (just now) making
> another SAM video for my website. It shows the use of SAM to change the
> PATH. You can view it here:
>
> https://joeslife.org/projects/RS/pictures/flash/sam_demo2_f

Thanks for the video!

> I went to the website you named--thank you for that. It shows that I'm
> not alone in my work, after all.

You are not alone, others have done this since the 90s, but the tcl-based
environment modules that I linked to is the one that has become most used.

There is also another project which solves the problem using lua:

https://www.tacc.utexas.edu/research-development/tacc-projects/lmod

And a seemingly since long abandoned project which solved the problem
using C:

http://www.lysator.liu.se/cmod/

The original tcl implementation might be better described on wikipedia
than on their own web:

https://en.wikipedia.org/wiki/Environment_Modules_(software)

regardss Henrik

On Fri, 24 Mar 2023 06:35:22 -0000 (UTC), Henrik Carlqvist wrote:

[snip]

> Yes, this works with bash and I think that also other module
> implemantations usually also do so with bash. With other shells like
> tcsh they might instead use something like alias and eval.

Sounds interesting.
>
>> In response to your question, I spent a few hours (just now) making
>> another SAM video for my website. It shows the use of SAM to change
>> the PATH. You can view it here:
>>
>> https://joeslife.org/projects/RS/pictures/flash/sam_demo2_f
>
> Thanks for the video!

Sure. Thank you for giving me a little push to make it!
>
>> I went to the website you named--thank you for that. It shows that I'm
>> not alone in my work, after all.
>
> You are not alone, others have done this since the 90s, but the
> tcl-based environment modules that I linked to is the one that has
> become most used.

Wow. I didn't know that.
>
> There is also another project which solves the problem using lua:
>
> https://www.tacc.utexas.edu/research-development/tacc-projects/lmod
>
> And a seemingly since long abandoned project which solved the problem
> using C:
>
> http://www.lysator.liu.se/cmod/
>
> The original tcl implementation might be better described on wikipedia
> than on their own web:
>
> https://en.wikipedia.org/wiki/Environment_Modules_(software)
>
> regardss Henrik

Thank you for the great links. I'll add them to my website. They are
interesting all by themselves, but are especially of interest to me due
to their connection to my SAM.

Could it be that SAM stands for "SAM Ain't Modules"?

-Joe

On Sat, 25 Mar 2023 00:08:20 +0000, Joseph Rosevear wrote:
> Could it be that SAM stands for "SAM Ain't Modules"?

That might be a good choice. When I hear "SAM" I associate it to a
graphical tool in the CDE environment to administer HP-UX machines:

https://nixdoc.net/man-pages/HP-UX/man1M/sam.1M.html

But today, that SAM is probably forgotten by most people. Maybe some
peopler are still running HP-UX or CDE. Some googling indicates that HP-
UX might have been updated as late as year 2020.

regards Henrik

On 2023-03-23 at 03:55 ADT, Henrik Carlqvist <Henrik.Carlqvist@deadspam.com> wrote:
> On Thu, 23 Mar 2023 00:06:14 +0000, Joseph Rosevear wrote:

>> But what if some of the commands actively managed the current
>> environment including the PATH?

>> That is what I have done.

> The problem with the environment variables like PATH is that it can be
> inherited by child processes, but a child process cannot alter the
> environment of a parent process.

I saw some horrible hack in some other newsgroup where someone showed how
(sort of, it didn't work for me) to do this using a debugger to attach to
the parent process and update the parent's environment.

The person claimed it worked for him, and, if so, this violates one of my
long-held beliefs about "child can't affect parent's environment".
However, it is a bit of a cheat, since (presumably) if that works, then any
process with perms to attach a debugger to a particular process could
change its environment.

Proof that this actually could work is left as an exercise to the diligent
student. :-)

Jim

On Sat, 25 Mar 2023 10:50:05 -0000 (UTC), Henrik Carlqvist wrote:

> On Sat, 25 Mar 2023 00:08:20 +0000, Joseph Rosevear wrote:
>> Could it be that SAM stands for "SAM Ain't Modules"?
>
> That might be a good choice. When I hear "SAM" I associate it to a
> graphical tool in the CDE environment to administer HP-UX machines:
>
> https://nixdoc.net/man-pages/HP-UX/man1M/sam.1M.html
>
> But today, that SAM is probably forgotten by most people. Maybe some
> peopler are still running HP-UX or CDE. Some googling indicates that HP-
> UX might have been updated as late as year 2020.
>
> regards Henrik

Well, alright. Maybe I'll go with that.

It's not a big deal, as my SAM is not invoked by typing "sam" (or
"SAM"). There are within my SAM two scripts with names of that ilk
("sam" and "sam1"), but I don't believe they are normally in the PATH.

My SAM is not installed as you would normally install an application, so
it is not invoked through the PATH. To install it, you simply put it
somewhere. (Although SAM uses three compiled C language executables, it
has both 32 and 64 bit versions available and chooses between them.) I
like to keep SAM at /mnt/joe_root which is a symlink to partition 1 on a
flashdrive, but the location doesn't matter. To run it, you simply
invoke it:

/mnt/joe_root/begin

I showed this in my demo video that I referred to in an earlier post.
The video was low quality, as I compressed it to make uploading and
downloading faster. You can, however, see a high quality version of the
video on youtube:

https://www.youtube.com/watch?v=5kp9_XSPXIU