Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: ENV: variables
Message-ID: <8809090704.AA15448@cory.Berkeley.EDU>
Date: 9 Sep 88 07:04:34 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 31

:> [...] Private variables on the Amiga?  YOU BET!  Damn right, a
:> requirement...  but not necessarily implemented by the enviroment
:> variable's domain... more like local shell variables.  [...]
:
:How's a call to getenv() going to pick off the value for a variable
:which is only known by the shell?

	It isn't... the routine in the shell that handles getting variables
will first search its own internals, and then resort to getenv().  

	My point here was that everything need not be implemented with
enviroment variables.  Those programs which are sophisticated enough will
always have a super-set of what the core Amiga provides.

:> [...] And if you *really* want private enviroment variables simply make
:> a sub-directory in ENV: ... but the program(s) would have to support
:> it. [...]
:
:Why make the program support it when you can do the same thing
:transparently?

	Well, not entirely transparent.  For instance, program X might
always look for a specific enviroment variable name 'XFONT', in which case
you are stuck with ENV:XFONT.  Sure, you can re-assign ENV: but that isn't
100% acceptable considering that other programs will go through ENV: as it 
becomes more widely used, possibly without the user knowing (i.e. background
processes).

	As far as the user being able to specify the enviroment variable
name, it can be made transparent.

				-Matt