Re: Windows env-Bug?

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
environment which Tcl sees. Tcl goes so far as to export a Tcl_PutEnv (i
think) so traces can fire, but is meaningless to code that uses the real win32
system environment access functions.

Who weighs more there? The real system environment to obtain correct answers,
or libc's buggy behavior due to system differences which has the ability to
fire traces?

Here's that compromise part in all its ugliness.

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.


--Joe English
.