Path: utzoo!utgpu!water!watmath!clyde!att!rutgers!cmcl2!nrl-cmf!ames!ucsd!ucsdhub!esosun!seismo!uunet!iscuva!ricks
From: ricks@iscuva.ISCS.COM (Rick Schaeffer)
Newsgroups: comp.sys.amiga
Subject: Re: Enviroment
Message-ID: <1887@iscuva.ISCS.COM>
Date: 20 Aug 88 16:19:26 GMT
References: <8808192105.AA16960@cory.Berkeley.EDU>
Organization: ISC Systems Corporation, Spokane, WA
Lines: 23

In article <8808192105.AA16960@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes:
>	1.3 has got enviroment variables.  Guess how they're implemented!
>
>	Yup, disk based.  You have a directory called ENV:, containing files
>	whos names are the enviroment variables and contents the contents for
>	those variables.  Eventually, C-A says, ENV: will become a device.
>

One suggestion...could CSH make a COPY of ENV: for any child it spawns?
That way the child process could muck around with the environment...change
paths...  etc without affecting the parent.  Maybe something like
"ENV:CLIn/$var" where n is the process number (cli number) of the child and
before calling the child you copy all of your environment into the new
directory.  That way you can STILL have a global environment ("ENV:$var")
and each sub-process can have an environment of it's own.  Add a couple
of new commands: "gset" and "gunset" that work in the global environment
and let "set" and "unset" work in the "local" environment.

-- 
Rick Schaeffer          UUCP:  uunet!iscuva!ricks
ISC Systems Corp.              ricks@iscuva.ISCS.COM
Box TAF-C8              Phone: (509)927-5114
Spokane, WA  99220