Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!apple!bionet!ig!agate!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Enviroment (was Re: Yea, but can an Amiga Shell do this....)
Message-ID: <8808232112.AA28387@cory.Berkeley.EDU>
Date: 23 Aug 88 21:12:11 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Lines: 66

:There is a way to do it, which is to have a subdirectory for each
:process in the tree.  When a child process looks for a given context 
:variable, it looks in its own subdirectory first, then, if it doesn't 
:find the given variable, it looks in its parent's directory and so on.  
:This gives inheritance behavior using a file-structured device and 
:without duplication of data.

	There are *lots* of things you can do, but it requires a certain
amount of sophistication on the programmer's part.  What I meant to say
is that giving some process a set of enviroment variables which are
different from the parents is not something that is easily accomplished
in a compatible way without much sophistication.  

	For instance, if you ran an editor TWICE and want to give EACH 
a different enviroment, it requires a certain amount of sophistication.
Too much to be worth it, I think.  Sure, you can do it, but whos gonna
want to do it?


:There are a couple of added advantages to this method over the SetEnv 
:interface.  You can modify the context variables for a different process 
:by changing files in its subdirectory.  Also, subdirectories could stick 
:around after the process exits so that when the same process starts up 
:again, it goes back to having its context set up the way it was last 
:time.

	I agree.  I like the idea of subdirectories in ENV: ... really
only useful if a given application requires the use of sooooo many 
enviroment variables that it would clutter up the main directory, but there
are definate advantages beyond that.

:It might be nice, however, to have an environment search path, so that 
:permanent environment vars could be set up on hard disk, and temporary 
:changes for the current shell could live on RAM:.  Just an idea.

	Right!  How about this:  Implement softlinks by allocating one of
those precious protection bits!  Make it mean 'softlink', where the contents
of the comment field would then be the link path.  It would be nice if
somebody could hack the filesystem to do this automagically.

:Why impose that constraint?  IFF would be nice for ENV: files such as
:Workbench-Backdrop and Guru-Sound.  :-)
:
:|                                 -Matt 
:-- 
:		Stuart Ferguson		(shf@well.UUCP)

	Oh yucc.  I figure enviroment variables should be *easy* to 
manipulate.  What we need is some distinction between IFF and a simple
text string.  How about this:

	An enviroment variable is broken up into two parts.  (1) An
enviroment text string terminated with a \0 (any number of newlines inbetween),
(2) An IFF file.  Thus, a variable which is ONLY IFF would simply have a 0
byte at the beginning of the file, and a variable which is ONLY A STRING would
simply be that string (\0 termination not needed if no IFF file follows).

	Hmm.. may want to make that four 0 bytes (or N, max 4, to longword
align the IFF header so access can be optimized).

	This would allow both unsophisticated (the majority of usage) and
sophisticated (special case) usage of the enviroment.  It would also allow
a shell command called 'printenv' give useful information for IFF files,
since those files might be preceeded by a comment (the text\0).

					-Matt