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