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'?