Re: Windows env-Bug?

On Thu, 26 Jul 2007, Joe English wrote:

David Gravereaux wrote:

Currently, a DLL (in the chain of things) might call win32's
SetEnvironmentVariable() which is not reflected by libc's cache of the real

....

That's another reason I think Tcl's treatment of ::env
ought to be changed. Instead of trying (and often failing)
to keep ::env in sync with the system environment at all times,
Tcl could initialize ::env from the system environment
at program startup only.

Slave interps and new threads would inherit ::env from their
parent interp, and the current interp's ::env would be used
to initialize the system environment for child processes
spawned via [exec], [open "|..."], and the like.

Decoupling ::env from the system environment after initialization
would also solve a number of thread-safety problems.

What do you mean by "Decoupling"?

Controlling (and not "monitoring") the process environment is one of the
basic methods of the "interprocess communication", its one way to
forward informations to subprocesses and change information on current
process level.
The "current process level" arguments is discussed controversly, I don't
know a standard for that as the $env mechanims has been created very
long before threads hav been introduced.

In my specific situation I have to create more that 100 environment
variables which are required by the subprocess (configuration options).
One specific reason for using Tcl is, that some unix tools (awk, sed,
....) fail by working too long variable values and I think this may also
be a problem under windows in some situations (eg. very a log PATH
variable?).

Tcl has no problem with very long lists, variable contents ... an also
allows platform indepenent path handling.
Thus it is the perfect platform independent "configuration machine" in
this situation and allows very convenient and efficient "environment
handling" for subprocesses.
But it must be ensured, that the internal state of ::env variable
reflect the platform specific environment of the subprocess.

One more reason to work on ::env is the fact, that windows treats
environment variables case-insensitive, unix does not:

Unix:
% set env(a) 1
1
% set env(A) 2
2
% puts "$env(a) $env(A)"
1 2

Windows:
% set env(a) 1
1
% set env(A) 2
2
% puts "$env(a) $env(A)"
2 2

parray only lists env(a) (the 1st one).

--
Gerhard Reithofer
Tech-EDV Support Forum - http://support.tech-edv.co.at
.

Relevant Pages

  • Re: define and assignment
    ... which draws environment models as the user types ... Memory locations are the addresses of objects. ... void define(symbol sym, expression expr, environment env) ... location set!(symbol sym, expression expr, environment env) ...
    (comp.lang.scheme)
  • Re: Design Patterns and Functional programming
    ... need that environment when evaluating. ... local env (static chain). ... object stored in the temporary value stacks or bound to a name in the ...
    (comp.object)
  • Re: Problem wih characters (was Problem with IME)
    ... even *heard* of an "env" utility. ... LANG=ja_JP.UTF-8 environment, although I suspect it wouldn't have any ... When I tried running it in a shell, ... But I am going to study Tobias Diedrich's suggestion very hard. ...
    (sci.lang.japan)
  • Re: Strange things in Yum
    ... try env command and look for HTTP_PROXY environment variable. ... That also throws error as it seems to read the same env varibles used to defin a proxy as yum does. ...
    (Fedora)