Path: utzoo!utgpu!attcan!uunet!seismo!sundc!pitstop!sun!quintus!pds
From: pds@quintus.uucp (Peter Schachte)
Newsgroups: comp.sys.amiga
Subject: Re: ENV: variables (long)
Keywords: grouping environment variables (was: global vs local variables)
Message-ID: <386@quintus.UUCP>
Date: 12 Sep 88 22:53:55 GMT
References: <8809090740.AA16138@cory.Berkeley.EDU> <151@antares.UUCP>
Sender: news@quintus.UUCP
Reply-To: pds@quintus.UUCP (Peter Schachte)
Organization: Quintus Computer Systems, Inc.
Lines: 27

In article <151@antares.UUCP> jms@antares.UUCP (joe smith) writes:
>Group variables are in the form
>"groupname.varname" ....  Shell variables are of the form "shell.*"
>(such as "shell.path=(/usr/bin /usr/local/bin"), which is better than
>the Unix convention.  Instead of storing compiler options in names like
>FOOBAROPTS, names like FOOBAR.WIDTH, FOOBAR.LINESPERPAGE, FOOBAR.MODE are
>possible.  The command "list-var FOOBAR.*" lists only the FOOBAR variables.

It sounds like a good idea to group variables by use.  But this is
something that's doable now with TOOLTYPEs:  you group all of a tool's
vars WITH THE TOOL.  This has the advantage that when you move a tool
from one disk to another, the variables move with it.  This seems like
a better way to handle this.  I believe it's also possible to have
different variable bindings for different data files (e.g., different
bindings for different IFF files used by the same bitmap editor).

The only problem is that a program has to have an icon, and (I think)
has to be started from the icon, in order to see these variables.  It
would be really nice if this restriction could be removed for a later
OS release.  (I know, I know:  where would you put the tooltype info if
not in the .icon file?  I have an answer to that:  make the file system
support an unlimited amount of user-definable data associated with a
file, but not IN the file, per se.  Like file dates and comments, only
extensible.)
-Peter Schachte
pds@quintus.uucp
..!sun!quintus!pds