The env array is one of the magic names created by Tcl to reflect the value of the invoker's environment; that is to say, when one starts Tcl, what one does is make a request to the operating system to start a new process. If the process is being started directly, that process is typically given a set of variables called environment variables which reflect certain default values. When Tcl starts, it creates the env array and reads the environment. Each environment variable becomes a key in this array whose value is the value of the environment variable.
For instance, on Unix, one will typically find keys like
To access the env array within a Tcl proc, one needs to tell the proc that env is a global array. There are two ways to do this.
The variables that appear in $::env are only those variables whom the parental shell places into the environment. Under bash/ksh/sh this is done by a line such as:
MYVAR="this is a test" ; export MYVAR
while in csh/tcsh, you do it like this:
setenv MYVAR "this is a test"
Shell variables set but not put into the environment are not accessible by child processes.
Also note that while a Tcl program can set new variables or values in $::env , those values will NOT be reflected in the program's parent process.
This separation of process data is an intentional part of the various operating systems available today. To communicate new variables or variable values back into the parent, one needs some sort of out of band communication of information; perhaps writing a shell script or file of data which the parent shell then reads.
DKF - Additional notes
The env array is precisely the environment variables of the current process. If you want to pass a variable to a child process, setting it in env is the way to do it. And on Windows, you can't set an environment variable to an empty string, as the OS defines that to be the same as removing the variable completely. (Stupid, but that's the way things are, and working around it - which is possible BTW - is not a good idea as it can cause trouble for some programs to receive empty env-vars when they don't expect it. Keeping the tight binding is thought to be a better idea.)
There is only one env array per process. All interpreters in all threads see the same data (though IIRC safe interpreters don't see the env array at all) and a change made by one can be seen by all. This makes access to the array quite slow, and I don't recall if there are cross-interpreter/cross-thread traces (though I suspect not, so you can't use it as an inter-thread communication mechanism. Use something designed for the task instead.)