Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!pasteur!ucbvax!hplabs!hpfcso!hpfelg!koren
From: koren@hpfelg.HP.COM (Steve Koren)
Newsgroups: comp.sys.amiga.tech
Subject: Re: ENV: is not multiuserable?
Message-ID: <13920047@hpfelg.HP.COM>
Date: 13 Feb 90 15:39:37 GMT
References: <02160.AA02160@thekeep.UUCP>
Organization: HP Elec. Design Div. -FtCollins
Lines: 27

> #Could some kind soul explain why everyone seems to want to do
> #their own environment variables?  There's a set in ENV:, a set
> #in matt's csh (or steve's ksh), and a set created with the Manx "set".

At the moment, most shells (mine, Matt's, etc) need variables which are
"local" to the shell (and *fast* to get at).  Un*x shells do the same
thing, actually - they keep their own var list.  However, the environement
stuff is handled differently there (environments are inherited, not
global).  SKsh (and I believe Matt's csh also, but not sure there)
provides a method to set and read ENV: variables.  In SKsh, you use
export (SKsh -> ENV:) and getenv (ENV: -> SKsh).

> good reason why 3rd-party shells couldn't use one of the standard systems for
> exported variables.

At least one of them does!

Anyhow, I think that C-A's ENV: solution is really not that bad of a hack.
It's just that it meets a slightly different need (inter-process variable
sharing) than the shell builtin variables.  Sure, one could envision
extending it in several ways (process specific vars, etc), but even with
that addition, SKsh would still have to implement its own mechanism.  For
example, you can have a function call another function in SKsh - both
are the same process, yet each can have its own value of the same variable
(as in C or Pascal or whatever).

     - steve "likes the Amiga even with global env variables" koren