🚀 go-pugleaf

># 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).

I was also involved in that argument.

># 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.

I agree.  I think the problem was that Matt Dillon liked it, and that
was good enough for CBM.

> 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>.

Matt Dillon proposed something like this in response to my objections.
The problem is that it must be supported this way in the default
library.

The only time I really care about envariable name space collisions is
when I am using commercial software (or other software for which I
don't have the source).  If I compiled the code, I can always work out
a way to avoid the collision.  But the only way we can get commercial
software to use a method such as your proposal is if it officially
supported.  In other words, if you call getenv() or something similar,
it should do this mapping for you.  The programmer never deals with
it.

So until either Commodore, or Manx and Lattice, define ENV: to work
this way, we will be stuck with the current problems.

> Steve Tell					tell@wsmail.cs.unc.edu
--
	Charles Brown	charles@cv.hp.com or charles%hpcvca@hplabs.hp.com
			or hplabs!hpcvca!charles or "Hey you!"
	Not representing my employer.