🚀 go-pugleaf

In article <02160.AA02160@thekeep.UUCP> terry@thekeep.UUCP (Terry D. West) writes:
#
#This has probably come up before (I recall a bunch of stuff on the
#ENV: handler a month ago that I put in my kill file :-)...
I was small participant in that, and have thought some more about it and have
an idea (see below).
#From what I can gather from the "Enhancer Software" "manual", ENV:
#is just a pointer to a block device where files are store by
#the name of the environment variable, their contents being 
#the contents of the variable.
#
#What a kludge.
Yep.
#This would seem to imply that the "multiuser" amiga where you and
#your spouse both have seperate shells have to share the SAME 
#environment variables (or alternately have an env var stomping 
#contest using a single keyboard :-)
#
#Could some kind soul explain why everyone seems to want to do
#their own environment variables?  There's a set in ENV:, a set
#in matt's csh (or steve's ksh), and a set created with the Manx "set".

#Is there not some way we can come up with a unified proposal for
#environment handling that paves the way for future mega power and
#a unified interface? Something that C-A and Manx and Matt and
#Steve would all with joy and wonder (a little thick, i admit)
#adopt?

There was recently posted an ENV-handler that acts like the ENV: filesystem
but uses Manx's environment library and thereby unifies the Manx and CBM
environments.  I haven't tried it, but I could send it to you.  There's no
good reason why 3rd-party shells couldn't use one of the standard systems for
exported variables.  (For variables local to a script they obviously want to
keep things local for efficiency.)

The main complaint to changing way environments are handled to allow multi-
user unix-semantics environment variables is that it would be incompatible
with what we already have.  Another standard seems to be not worth the trouble.

My idea:
Keep using ENV:.  Pehaps use the ENV-handler.
Store environment variables in a file called "ENV:<process-id>/<variable-name>.
For compatibility, also allow ENV:<variable-name>.

When a program starts up, it finds the process ID of its parent and copies all
of the variables to its own ID.  Perhaps someday this could be built into
CreateProc or elsewhere in the system.  To cut down on the memory used,
ENV-handler could support links, or it could do some internal linking when two
variables have the same contents.  When a program exits, it deletes its
environment variables.

Ideally, the shell would set up the environment for the child, and clean it
up, but the shell doesn't know the process-ID (address of struct process)
until the child is running, or does it?

Old programs would still access ENV:<variable-name>, so some reasonable
system-wide defaults could be kept there.

I can see two possible drawbacks:  (1)Lots of overhead setting up an
environment that may never get used by a process. (2) Tasks can't call DOS to
open files in ENV:, they would have to use the library directly and wouldn't
know about changes made to its format.  Perhaps this is a non-problem.

#Ok, you can now flame me.  It just seems like the reasonable thing
#to do. (change the env system, not flame me!)
Well?
--------------------------------------------------------------------
Steve Tell					tell@wsmail.cs.unc.edu
CS Grad Student, UNC Chapel Hill.