Path: utzoo!attcan!uunet!super!udel!gatech!uflorida!ukma!david From: david@ms.uky.edu (David Herron -- One of the vertebrae) Newsgroups: comp.sys.amiga Subject: Re: ENV: variables (long) Message-ID: <10306@s.ms.uky.edu> Date: 28 Sep 88 15:56:02 GMT References: <374@uwslh.UUCP> <5660014@hpcvca.HP.COM> <2629@sugar.uu.net> <4781@cbmvax.UUCP> <933@tragicomix.liu.se> <70139@sun.uucp> Reply-To: david@ms.uky.edu (David Herron -- One of the vertebrae) Organization: U of Kentucky, Mathematical Sciences Lines: 36 I don't particularly care HOW environment variables are implemented so long as there are some nice flexible ways of dealing with them. This must allow global variables, overriding particular variables for particular process(es), and inheritance. I don't think anybody would argue with me over this set of features. They may not want ALL of the features, but in turn if they want less features they simply don't have to use them. People have said that you can have 'local' variables by simply using sub-directories of ENV:. But this isn't acceptible. As an example, take command execution. There is a need for command execution paths which vary between different processes. (If you don't know why, ask and I'll say why). I am not completely certain of how it's done now ... is it that you ASSIGN a list of path-specs to the C: device? But aren't ASSIGN'd thingys global? Instead how about ... a PATH variable? So you implement this in whatever system-call exec()'s processes. It looks down the PATH variable looking for the command. So the routine does getenv("PATH"); to get the path-list, right? Now, how do we override this with sub-directories? Something which occurs to me is to have getenv() pre-pend something like "Proc-#/" as a first attempt. Possibly also have some other rules for other similar 'probes'. hmm... How about a variable ENVPATH which is a similar list of directories in which to find environment variables? Or maybe ENV: could be an ASSIGN'd list ('cept ASSIGN'd lists are global, right? and again, there is need for per-process versions of this) just a lil' ramblin' after a numerical analysis test ... -- <-- David Herron; The official MMDF guy of the 1988 Olympics<-- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <-- What does the phrase "Don't work too hard" <-- have to do with the decline of the american 'work ethic'?