Path: utzoo!utgpu!water!watmath!clyde!att!alberta!ubc-cs!uw-beaver!cornell!batcomputer!itsgw!steinmetz!uunet!cbmvax!jesup From: jesup@cbmvax.UUCP (Randell Jesup) Newsgroups: comp.sys.amiga Subject: Re: Enviroment (was Re: Yea, but can an Amiga Shell do this....) Message-ID: <4529@cbmvax.UUCP> Date: 22 Aug 88 00:50:13 GMT References: <8808192105.AA16960@cory.Berkeley.EDU> <5660008@hpcvca.HP.COM> Reply-To: jesup@cbmvax.UUCP (Randell Jesup) Organization: Commodore Technology, West Chester, PA Lines: 34 In article <5660008@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >How does this allow a child to have an environment different from its >parent? Specifically > > grandparent > | | > parent1 parent2 > | | > child1 child2 >It looks like the ENV: solution will have all >of these processes writing to the same files and so all will share the >same environment. Yup. If some program/shell needs locals they don't want have to worry about collision (i.e. it's going to change them, for example), then put use the CLI number of the process in the var name (or put them in a sub- directory of that name). If you are using subdirectories, don't forget to makedir them before writing the file, if doing it from a program. This may change if we ever do a real ENV: handler, but even then it won't hurt to makedir the directory. In reality, almost all uses of envirionment variables are to supply parameters and defaults to programs, like EDITOR. The commodore shell in 1.3 uses the ENV: variables for it's shell variables. Most CShell clones (like mine and I suspect Matt's) will use them, but search internal shell variables first, mirroring Unix shell var/env var semantics (mostly). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup