david@ms.uky.edu (David Herron -- One of the vertebrae) (09/06/88)
There has been recent discussion of the ENV: stuff in 1.3 ...
One of the things which has really hit a nerve with me is Matt saying
that he really doesn't like Environment variables as implemented in
Unix. (As I recall, he also doesn't like the fork()/exec() split ...
but I'm going only going to talk about environment variables).
Let's ignore the implementation for a moment.
The Unix method, while having some inefficiencies, has a number of
features which are very useful. For instance, not all variables
are exported to other processes -- allowing one to have temporary
variables without worrying about other processes. For instance,
the environment variables are not global to the whole system but
instead to children of the process which initialized the variable --
allowing background daemons to have access to different commands
than do the users, or in general to let the individual process
groups specify what variables are important and what the values
should be. I'm sure there are others, but these are the ones
I find important.
At first glance it may seem that neither of these are important in
a non-multi-user machine like an Amiga. Most of the script based
things which are similar to shell scripts already have a facility
for local variables, and Amiga's don't often have background daemons.
The 'local variables' part of the problem is 'solved' already.
As for different processes needing different environment variables.
There are lots of reasons for wanting to be able to do this. Suppose
some package (including what I said about background daemons above)
needs to have access to a set of programs which you don't want people
to be running at random. You place them over in some directory.
The programs in the package set up a PATH variable for themselves
which includes that directory, and other people simply ignore the
directory. This can be either from 'shell scripts' or from within
'real' programs.
It wouldn't be 'friendly' for the package to modify the global PATH
variable because this is a multi-tasking machine and you never know
when the user is going to go to a CLI window to do something and get
confused by a strange PATH variable.
I don't particularly care how it's implemented so long as the capability
is there to have different sets of environment variables for different
groups of processes.
You might say that since the Amiga is a single-person machine it's not
going to need full-blown capabilities like we have on Unix machines.
Weee-eeell.. first off, that's a ridiculous assumption as the machine
*is* fairly powerful. But also the world is changing ... the other
major players in the personal computer market are busily putting
multi-tasking into their computers. This and the growth of data
communications is going to collide into a need/desire for people to
have their computers be able to do networking tasks 'in the background'
while they continue to work 'in the foreground'. Much like this
workstation I'm using is a fully capable internet host -- capable of
supporting remote users logging into this machine, sending/receiving
mail, running applications on other machines on the network, and a host
of other capabilities.
Probably my view is limited because I concentrate on communications
in the first place. But what I said in the previous paragraph is
true, people will be expecting more capabilities out of their machines
as multi-tasking becomes more and more prevalent. Now, the important
thing here is 1) that we not limit the generality of features present
in the Amiga and 2) that 'background daemons' in general (and communications
daemons in specific) tend to use wildly different command sets than
the normal user does.
The context for my remarks? I run the e-mail/news/bitnet/internet/uucp
software for the CS/MA/STAT departments here, and have been involved
in running the systems here for 4 1/2 years. I have been writing shell
scripts used in 'background daemon' type functions for most of that
4 1/2 years and have quite a bit of experience in operating a system
with background daemons.
--
<---- David Herron -- One of the MMDF guys <david@ms.uky.edu>
<---- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET
<---- The owner of the talkative, blatant and period bikini is a Van Halen fan
<---- I'm a Talking Heads fan ... can you say 'incompatible'?dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/07/88)
:There has been recent discussion of the ENV: stuff in 1.3 ... : :One of the things which has really hit a nerve with me is Matt saying :that he really doesn't like Environment variables as implemented in :Unix. (As I recall, he also doesn't like the fork()/exec() split ... :but I'm going only going to talk about environment variables). Uh oh! Well, let me put it this way. Please keep the perspective that this is an AMIGA, *NOT* a large multi-user UNIX system. You can't just keep a million copies of a possibly huge enviroment set lying around in memory now can you! (1) One might want it to be the same globally (2) One might want it to be the same for a particular login shell and programs running under that shell (3) One might want a private copy for a particular running process -- Now on UNIX, all enviroment variables are private and can only be propogated to children. I.E. (3). There is no way to change the enviroment variables associated with already-running processes unless that process does it itself. Now do a printenv on your machine... how many of these variables are the same for all possible logins to your account? Here I am NOT talking about user-independance... the Amiga is more a single-user machine then anything else, even more so then the workstation class. In my enviroment I count about 12 out of 16. The ones that might change are, for instance, the terminal type and termcap, and these do not have much of a bearing on the Amiga. 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. Passing a specific variable to a program where the program might already be running 'in another window' where you WANT the variable to be different? Well, this situation can certainly come up (I have yet to be in such a situation). Again, the fact that the Amiga is not a multi-user systems saves us. setenv var #1, run program, setenv var #2, run program, which assumes that the program reads the enviroment variable at startup (most will). And if you *really* want private enviroment variables simply make a sub-directory in ENV: ... but the program(s) would have to support it. -Matt
dml@loral.UUCP (Dave Lewis) (09/07/88)
In article <8809070041.AA11163@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >:There has been recent discussion of the ENV: stuff in 1.3 ... > And if you *really* want private enviroment variables simply make > a sub-directory in ENV: ... but the program(s) would have to support it. > -Matt But Matt, you already GOT that! (you DO use your Shell, don't you?) Use the Arp C:Set command for global variables that are accessable to any process, and the Shell's built-in "set" for privates. Admittedly, these are not part of the "standard" AmigaOS, but they are both public domain. This system works fine for me on my Aztec disk - the compiler's INCLUDE, CCTEMP and CLIB variables are global and each shell gets to create its own _path, _prompt and so on. I'm going to add support for the Arp Set variables to the Shell (along with all the other stuff I'm adding). I'm making so many changes that this thing could qualify for a new release instead of just diff's. BTW, I did figure out the semicolon business with Arp's Set: 1> Set "INCLUDE=path1;path2;path3" "CLIB=path4;path5;path6;;" works just fine. Advice: don't screw around with new stuff in the middle of the night. It produces symptoms remarkably similar to a hangover. Still haven't figured out how to use Resident and ARun with programs that don't open their own windows, though. I WANT to make the Shell Resident. -- Dave Lewis Loral Instrumentation San Diego (619) 282-3341 ihnp4 --\ bang --\ kontron -\ hp-sdd --\ calmasd ->-> crash ->--> loral!dml sdcrdcf -->--------> sdcsvax -/ (uucp)
jdh@bsu-cs.UUCP (John Hiday) (09/08/88)
In article <8809070041.AA11163@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > Uh oh! Well, let me put it this way. Please keep the perspective >that this is an AMIGA, *NOT* a large multi-user UNIX system. You can't just >keep a million copies of a possibly huge enviroment set lying around in >memory now can you!.... This is another situation in which ASSIGNing to a path rather than to a specific directory would work great. Simply assign ENV: first to a process specific directory, then to a system wide one. If you want to redefine a variable for local use only, you just stick it in the process-specific env directory. That way each process only needs its own copy of the variables which are different from the system-wide ones. Since it would simply be based on a path of directories, this approach would not be limited to just a system-wide set and a process local set. If you have a group of programs which need a special set of variables, simply stick another entry into the ENV: path. > [...] 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? > [...] 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? -- UUCP : <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!jdh John Hiday BITNET: 00JDHIDAY@BSUVAX1.BITNET Ball State Univ Computing Services GEnie : JDHIDAY Muncie, IN 47306
lishka@uwslh.UUCP (Fish-Guts) (09/08/88)
In article <8809070041.AA11163@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > >:There has been recent discussion of the ENV: stuff in 1.3 ... >: >:One of the things which has really hit a nerve with me is Matt saying >:that he really doesn't like Environment variables as implemented in >:Unix. (As I recall, he also doesn't like the fork()/exec() split ... >:but I'm going only going to talk about environment variables). > > Uh oh! Well, let me put it this way. Please keep the perspective >that this is an AMIGA, *NOT* a large multi-user UNIX system. You can't just >keep a million copies of a possibly huge enviroment set lying around in >memory now can you! I really do not see where Unix environment strings take up all that much memory per user. I am a programmer, and I assume that I would have at least the *average* number of variables defined in my environment. Now, doing a "set | wc" (I am using ksh, BTW) I get 34 lines of variables set (i.e. 34 variables) and 802 characters of variable names and values; therefore, being liberal, I would use 34 variables at a memory cost of ~1k bytes. I should also note that most of the users around here (microbiologists who know little about computers) probably have less than ten variables set. Now, the typical Amiga is a single-user machine. Therefore, only one user's set of variables need be in the machine (typically). If each new program that is run is passed a full set of environment variables, then one would have a typical overhead of about 1k bytes per program. If one runs about 5 programs normally at once (because we have multitasking), then the machine would lose 5k bytes of memory. Even if people like to invoke a lot of programs at once (say, 32 different programs running at one time), then the machine would lose 32k bytes of memory. Given that most people have 512k machines out there, I think that 5k lost normally is not all that bad. If we *really* want to become fanatical about memory, a system call such as free_env() could be cooked up to release the environment memory after it has been used for the program; each program would need to call it on their own, of course. So I really do not understand why environments take up sooooo much memory in Unix. I do not think they would take up that much memory in an Amiga if implemented in the Unix fashion. I think what will *realy* cause environment variables to consume a lot of memory is if people start sticking *pictures* and music scores in them. Let me see...a 640x200x2 bitplane backdrop picture would consume 32k (admittedly, this is for umcompressed pictures). That's as much memory used as the Unix method using my typical environment and 32 different programs. This will happen even with the present Amiga scheme for environment variable implementation. > (1) One might want it to be the same globally > (2) One might want it to be the same for a particular login shell > and programs running under that shell > (3) One might want a private copy for a particular running process > > -- > > Now on UNIX, all enviroment variables are private and can only be > propogated to children. I.E. (3). There is no way to change the > enviroment variables associated with already-running processes unless > that process does it itself. True: all environments come from a common "root," that being the shell that invoked the program in the first place. The variables can be changed as each new process is created. I do not see that as a limitation; I think private environments *are* a good idea. With the Amiga's implementation, one can reset a ENV: variable midway through another program's execution. How does this other program find out? Does it have to now-and-then poll the ENV: directory to see if the variable is different (probably by looking at the time of modification)? Besides, with a Unix environment the lookup of an environment variable is only a string search; on the Amiga it is opening a file and reading it (as I understand it). Which has more overhead? Certainly the Amiga version (unless one has a looooooooong Unix environment, which in my experience does not happen much). I think that if one process wants to change another processes environment, then it should do so through Inter-Process Communication. Changing the environment "under a processes feet," so to speak, it rather sneaky in my point of view. Personally, I *like* private environments. > Now do a printenv on your machine... how many of these variables > are the same for all possible logins to your account? Here I am > NOT talking about user-independance... the Amiga is more a single-user > machine then anything else, even more so then the workstation class. > > In my enviroment I count about 12 out of 16. The ones that might > change are, for instance, the terminal type and termcap, and these > do not have much of a bearing on the Amiga. Let's see...I have 34 or more variables defined. This will grow and shrink because I have variables track the many directories which I have visited. Most of the other variables (probably 75% to 80%) will not be modified by me. However, I cannot guarantee that other programs will *not* modify the variables for their children. Yeah, you're right...there is quite a bit of redundancy. However, I like the idea of saying, in the middle of a program: "Hey! I need to invoke a child process (say, lpr) with a different variable value (say, changing the current PRINTER value). Let's see, all I need to do is (a) change the PRINTER variable; (b) do a fork/exec combination." Now, I have effectively changed the environment for *only* that program. With the Amiga, you change this variable globally. Unless the sub-directory method is used (which seems like a lot of overhead to me, creating a new directory block and entries), there is no way to easily achieve the same effect. > 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. Unix has this too. Each shell has a method of defining normal shell variables (csh and ksh use different flavors of "set" to do this) and environment variables (csh uses "setenv"; ksh uses "export <VARIABLE_NAME>"). Only ksh ties the shell-variable to the environment-variable. I prefer ksh's method. I am not fond of having private shell-variables with the same name as environment-variables (I know, I know, I shouldn't use the same names ;^) > Passing a specific variable to a program where the program might > already be running 'in another window' where you WANT the variable > to be different? Well, this situation can certainly come up (I have > yet to be in such a situation). Again, the fact that the Amiga is > not a multi-user systems saves us. setenv var #1, run program, > setenv var #2, run program, which assumes that the program reads the > enviroment variable at startup (most will). > > And if you *really* want private enviroment variables simply make > a sub-directory in ENV: ... but the program(s) would have to support > it. This seems more like a kludge to me. I would assume that the sub-directory method would have more overhead (by needing to create all the directory information as well as the file information for the new variable) in implementation. Plus, the sub-directory method *certainly* has more overhead when reading a variable: in Unix, all that is needed is a string search through the environment string; with the sub-directory method, you need to trace the path through the program's ancestor's sub-directories to get to the right program sub-directory. Now, I know the new FFS is fast, but "it ain't that fast!" Don't get me wrong. I do not mind the Amiga implementation of environment variables, but I think the Unix version has a lot of good points too. There are things you can do with one that you would not be able to do with the other...it works both ways. I am just thankful that the software engineers put environment variables in the OS. Thanks Commodore! Let's see, it's time to start thinking about defining my Amiga environment variables...there's ROGUEOPTS, HUNT...oh, damn, I don't have those programs on this machine. Well, maybe LARNOPTS, AMOEBAOPTS, JETOPTS, EBONSTAROPTS, etc. ;^) > -Matt .oO Chris Oo. -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 lishka@uwslh.uucp ---- "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/09/88)
:> [...] 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
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/09/88)
: But Matt, you already GOT that! (you DO use your Shell, don't you?) Use the :Arp C:Set command for global variables that are accessable to any process, and :the Shell's built-in "set" for privates. Admittedly, these are not part of the :"standard" AmigaOS, but they are both public domain. This system works fine for :me on my Aztec disk - the compiler's INCLUDE, CCTEMP and CLIB variables are :global and each shell gets to create its own _path, _prompt and so on. I'm :going to add support for the Arp Set variables to the Shell (along with all the :other stuff I'm adding). I'm making so many changes that this thing could :qualify for a new release instead of just diff's. : : BTW, I did figure out the semicolon business with Arp's Set: : :1> Set "INCLUDE=path1;path2;path3" "CLIB=path4;path5;path6;;" I suggest everybody, including the ARP people and Manx, switch over to ENV: ... I've already added ENV: support to DME and my Shell, both of which are now in Beta for the next release (send those bug reports!). HOW I'm going to post them I do not know yet. -Matt
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/09/88)
:>keep a million copies of a possibly huge enviroment set lying around in :>memory now can you! : : I really do not see where Unix environment strings take up all :that much memory per user. I am a programmer, and I assume that I :would have at least the *average* number of variables defined in my :environment. Now, doing a "set | wc" (I am using ksh, BTW) I get 34 But on my Amiga, I might want to put entire files in the ENV: ! For instance, default ICONs and other junk... -Matt
jms@antares.UUCP (joe smith) (09/10/88)
One interesting non-Unix OS has 4 levels of variables; 2 on disk, 2 in
memory. The order search is:
1) Check memory for definitions local to the current CLI
2) Check memory for definitions global to all CLIs from this session
3) Read user's permanent defaults from ~/vars/*
4) Read system-wide defaults from /vars/*
The set-variable command modifies only the local variables unless the
-global option is used, in which case the new value is visible to all
CLIs that were created by the current logon session.
When a new CLI is created, it inherits a copy of its parent's local
variables. The new CLI cannot modify its parent's local variables, and
cannot see any change to its parent's local variables, but it can see the
session-wide global variables if it chooses to. The routine to lookup
a variable will find the local value if one is defined, otherwise it
will find the global variable. A program can explicitly request the
global variable (bypassing the corresponding local value) if it wants.
Global variable names are uppercase, local variables are lowercase.
Generic variable names are a single word. Group variables are in the form
"groupname.varname" and are initialized from the file ~/vargroupname the
first time they are referenced. 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.
I would like to see something like this on the Amiga. In particular:
1) Global variables visible to all tasks.
2) Local variables per process, copied from parent when process is
created and easily located.
3) Routine to lookup a variable will find the local value if defined,
otherwise automatically search for the corresponding global value.
4) The ability to see both the local and global settings of the same
variable if desired.
5) Explicit grouping of variables, such as "groupname.varname", fully
supported by the OS.
--
+-----------------------------------------------------------------------------+
| TYMNET: JMS@F29 UUCP: {ames|pyramid}oliveb!tymix!antares!jms |
| INTERNET: JMS%F29.Tymnet@Office-1.ARPA PHONE: Joe Smith @ (408)922-6220 |
+-----------------------------------------------------------------------------+lishka@uwslh.UUCP (Fish-Guts) (09/10/88)
In article <8809090740.AA16138@cory.Berkeley.EDU> dillon@CORY.BERKELEY.EDU (Matt Dillon) writes: > But on my Amiga, I might want to put entire files in the ENV: ! >For instance, default ICONs and other junk... I do not intend to stretch this out, but you *can* put the name of a file containing a default icon in Unix-style environment variables, and then just access the file when needed. It would be more efficient to simulate the Amiga-env-variables with a Unix implementation (in the manner described above) than to simulate Unix-env-variables with an Amiga implementation and sub-directories. Again, I think that *both* methods have their merits, as well as drawbacks. I like the Unix style, but I can certainly live with the Amiga style. I just do not see why others look down on the Unix style environment variables so much (although their opinions are just as valid as mine). To each her/his own! > -Matt .oO Chris Oo. -- Christopher Lishka ...!{rutgers|ucbvax|...}!uwvax!uwslh!lishka Wisconsin State Lab of Hygiene lishka%uwslh.uucp@cs.wisc.edu Immunology Section (608)262-1617 lishka@uwslh.uucp ---- "...Just because someone is shy and gets straight A's does not mean they won't put wads of gum in your arm pits." - Lynda Barry, "Ernie Pook's Commeek: Gum of Mystery"
charles@hpcvca.HP.COM (Charles Brown) (09/12/88)
> One interesting non-Unix OS has 4 levels of variables; 2 on disk, 2 > in memory. The order search is: This proposal beats both the AmigaDos ENV: solution and the Unix solution hands down. > Global variable names are uppercase, local variables are lowercase. Is this enforced or is it just a convention? > 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. This is so sensible that it's frightening. > {ames|pyramid}oliveb!tymix!antares!jms | Charles Brown
pds@quintus.uucp (Peter Schachte) (09/13/88)
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
jesup@cbmvax.UUCP (Randell Jesup) (09/14/88)
In article <5660014@hpcvca.HP.COM> charles@hpcvca.HP.COM (Charles Brown) writes: >> 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 is suggested that users of ENV: use subdirectories to store application-specific envirionment variables, instead of global ones, to cut down on name collisions. The can be extended in some cases to include the CLI number or process address as part of the name (useful in scripts, since <$$> expands to the CLI number). -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.uu.net (Peter da Silva) (09/14/88)
In article <5660014@hpcvca.HP.COM>, charles@hpcvca.HP.COM (Charles Brown) writes: > > FOOBAROPTS, names like FOOBAR.WIDTH, FOOBAR.LINESPERPAGE, FOOBAR.MODE > > are possible. The command "list-var FOOBAR.*" lists only the FOOBAR > > variables. > This is so sensible that it's frightening. It's also possible on the Amiga. 1> Setenv foobar.width 10 1> dir env:foobar.#? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
jesup@cbmvax.UUCP (Randell Jesup) (09/21/88)
In article <2629@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: >In article <5660014@hpcvca.HP.COM>, charles@hpcvca.HP.COM (Charles Brown) writes: >> > FOOBAROPTS, names like FOOBAR.WIDTH, FOOBAR.LINESPERPAGE, FOOBAR.MODE >> > are possible. The command "list-var FOOBAR.*" lists only the FOOBAR >> > variables. > >> This is so sensible that it's frightening. > >It's also possible on the Amiga. > >1> Setenv foobar.width 10 >1> dir env:foobar.#? I'd greatly prefer it if people would use subdirectories (ex: "Setenv foobar/width 10", "dir env:foobar".) I see subdirectories as one of the nice side effects of using a filesystem for env variables (plus getting all those file manipulation programs like copy, rename, dir, etc for free, instead of having to write new ones just for the env variables.) -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
peter@sugar.uu.net (Peter da Silva) (09/21/88)
In article <4781@cbmvax.UUCP>, jesup@cbmvax.UUCP (Randell Jesup) writes: > In article <2629@sugar.uu.net> peter@sugar.uu.net (Peter da Silva) writes: > >1> Setenv foobar.width 10 > >1> dir env:foobar.#? > I'd greatly prefer it if people would use subdirectories (ex: > "Setenv foobar/width 10", "dir env:foobar".) Will the real ENV: device, should one actually come out, support subdirectories? -- Peter da Silva `-_-' peter@sugar.uu.net Have you hugged U your wolf today?
mikhe@tragicomix.liu.se (Mike Henry) (09/23/88)
[Munch, Munch, Munch... BURP!!] In article <4781@cbmvax.UUCP> jesup@cbmvax.UUCP (Randell Jesup) writes: > I'd greatly prefer it if people would use subdirectories (ex: >"Setenv foobar/width 10", "dir env:foobar".) > > I see subdirectories as one of the nice side effects of using a >filesystem for env variables (plus getting all those file manipulation >programs like copy, rename, dir, etc for free, instead of having to write >new ones just for the env variables.) > >-- >Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup Is this really an EFFICIENT idea ?? Please consider this: The example "Setenv foobar/width 10" will open a file "width" in the directory "foobar" with nothing more in it than the two characters "1" and "0" (well of course we get "\0" too, so make that three). How much space have we used to get a file that will hold just three characters ?? I smell a waste of space here, or have I missed something ?? Think about the MASS of environment variables that we all like to create for ourselves and the TIME it will take AmigaDOS to find the RIGHT variable among all of them. Wouldn't it be better (read: more efficient) if we tried to keep all variables in ONE file so that a certain program could read the file and (efficiently B^) extract the RIGHT variable and it's value without having AmigaDOS trash our floppies searching for an environment FILE with just THREE characters in it. [FLAME_OFF] Of course we could "C:Assign ENV: RAD:Env" and avoid trashing, but I speak for those that couldn't afford ASDG's 8Mb RAM expansion box. B^) --Mike Disclaim ? ME ? I don't even have an employer !! -- UUCP : mikhe@majestix.liu.se OR AMIGA /// {seismo,mcvax,munnari}!enea!liuida!majestix!mikhe /// ARPA : mikhe%majestix.{ida.liu.se,UUCP}@seismo.CSS.GOV \\\/// SNAIL: Mike Henry, Alsattersg. 3C:20, S-582 51 Linkoping SWEDEN \XX/ RULES
dillon@CORY.BERKELEY.EDU (Matt Dillon) (09/25/88)
> Is this really an EFFICIENT idea ?? Please consider this: >The example "Setenv foobar/width 10" will open a file "width" in the directory >"foobar" with nothing more in it than the two characters "1" and "0" (well of >course we get "\0" too, so make that three). How much space have we used to >get a file that will hold just three characters ?? I smell a waste of space >here, or have I missed something ?? Too right... but also remember that one's entire enviroment, even at 1K/var on disk, is still smaller than a tiny application program... especially on hard disk. So while disk space might appear to wasted, the actual space used is almost nothing compared to other things on the disk. And, of course, there is no waste in RAM at all .. just the # bytes the enviroment text takes. USING ENV: NOTE! If you are writing programs which set and get enviroment variables, remember that NO \0 IS PLACED AT THE END OF THE STRING IN THE FILE! ALSO, NO NEWLINE IS PLACED AT THE END OF THE STRING IN THE FILE! that is, for standard variables like: SetEnv CHARLIE Test The file would hold: 'T' 'e' 's' 't' ... nothing more. Files which contain whole lines of text or other things might have newlines in them, but here I am just discussion the standard one-liner's -Matt
cmcmanis%pepper@Sun.COM (Chuck McManis) (09/27/88)
First Randell wrote : > I'd greatly prefer it if people would use subdirectories (ex: >"Setenv foobar/width 10", "dir env:foobar".) Then in article <933@tragicomix.liu.se> (Mike Henry) writes: > Is this really an EFFICIENT idea ?? Please consider this: The example > "Setenv foobar/width 10" will open a file "width" in the directory > "foobar" with nothing more in it than the two characters "1" and "0" > (well of course we get "\0" too, so make that three). How much space > have we used to get a file that will hold just three characters ?? I > smell a waste of space here, or have I missed something ?? Well you have missed a couple of things. One in terms of search speed for the variable you want it is *very* efficient. That is because the Amiga's filename hashing algorithim can find files very quickly, probably as quickly as a shell could looking through it's own linked list. Secondly, while at the moment they are implemented as files on the assigned device what CBM has done is define the semantics for them. This is important, now the underlying mechanisim can be rewritten to increase the storage efficiency. In fact, one could probably whack Matt's ram-disk handler to do just that with a minimum of fuss and a maximum of efficiency. I could concievably enforce local variables by keying off the reply port for the packets that were sent to it. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
david@ms.uky.edu (David Herron -- One of the vertebrae) (09/28/88)
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 <david@ms.uky.edu>
<-- 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'?