Path: utzoo!attcan!uunet!super!udel!gatech!rutgers!uwvax!uwslh!lishka From: lishka@uwslh.UUCP (Fish-Guts) Newsgroups: comp.sys.amiga Subject: Re: ENV: variables (long) Message-ID: <374@uwslh.UUCP> Date: 8 Sep 88 13:49:23 GMT References: <8809070041.AA11163@cory.Berkeley.EDU> Reply-To: lishka@uwslh.UUCP (Fish-Guts) Organization: U of Wisconsin-Madison, State Hygiene Lab Lines: 171 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 "). 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"