terry@thekeep.UUCP (Terry D. West) (02/08/90)
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 :-)... 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. 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? Ok, you can now flame me. It just seems like the reasonable thing to do. (change the env system, not flame me!) Terry. ------------------------------------------------------------------------- Terry West ...watmath!mks!thekeep!terry 309-400 Parkside Dr. Waterloo, ON, Canada. N2L 6E5 "thekeep" is an Amiga! -------------------------------------------------------------------------
tell@oscar.cs.unc.edu (Stephen Tell) (02/12/90)
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.peter@sugar.hackercorp.com (Peter da Silva) (02/12/90)
In article <02160.AA02160@thekeep.UUCP> terry@thekeep.UUCP (Terry D. West) writes: > 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 :-) Since you want to have seperate assigns anyway in a multiuser system, why not just assign your local ENV: to different places. -- _--_|\ Peter da Silva <peter@sugar.hackercorp.com>. / \ \_.--._/ I haven't lost my mind, it's backed up on tape somewhere! v "Have you hugged your wolf today?" `-_-'
koren@hpfelg.HP.COM (Steve Koren) (02/13/90)
> #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". At the moment, most shells (mine, Matt's, etc) need variables which are "local" to the shell (and *fast* to get at). Un*x shells do the same thing, actually - they keep their own var list. However, the environement stuff is handled differently there (environments are inherited, not global). SKsh (and I believe Matt's csh also, but not sure there) provides a method to set and read ENV: variables. In SKsh, you use export (SKsh -> ENV:) and getenv (ENV: -> SKsh). > good reason why 3rd-party shells couldn't use one of the standard systems for > exported variables. At least one of them does! Anyhow, I think that C-A's ENV: solution is really not that bad of a hack. It's just that it meets a slightly different need (inter-process variable sharing) than the shell builtin variables. Sure, one could envision extending it in several ways (process specific vars, etc), but even with that addition, SKsh would still have to implement its own mechanism. For example, you can have a function call another function in SKsh - both are the same process, yet each can have its own value of the same variable (as in C or Pascal or whatever). - steve "likes the Amiga even with global env variables" koren
charles@hpcvca.CV.HP.COM (Charles Brown) (02/14/90)
># 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.