Mailing List Archive

Environment inheritance under Windows NT 4, Attempt 2
Since I've not yet gotten a response to my first post, here's an
elaboration.

Windows NT Workstation 4.00.1381, SP5.

1. Right click on My Computer, choose Properties, Environment tab. Note
the value of the System Variable "windir" and press Cancel. (On my
system, this is "C:\WINNT".)

2. Open a Command prompt.

3. Here's a transscript of my CMD session, you can follow along:

-----------------------------------------------------
C:\>echo %WINDIR%
C:\WINNT

C:\>python -c "import os; print os.environ['windir']"
C:\WINNT

C:\>set WINDIR=foo

C:\>echo %WINDIR%
foo

C:\>python -c "import os; print os.environ['windir']"
C:\WINNT

-----------------------------------------------------

What is going on here? I wrote a program using VC5 to extract a variable
(1) directly from environ and _environ and (2) by calling getenv(). All
three reported "foo". (Source provided below.)

After rummaging through the Python source, it appears that os.environ is
provided through the posix module, which in turn gets the environment data
from the "extern char** environ".

Could this have something to do with Microsoft's run-time DLLs? I noticed
that Cygwin B19 used to exhibit this behavior as well, but it seemed to go
away in B20.1.

Python picks up the environment correctly if I go into the Control Panel,
System, Environment, and click OK. But I have to do this each time I log
in to NT.


----------------------------------------------------------------------
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
#include <string.h>

extern char** environ;

#define BIG 80


int envIndex(const char** envArray, const char* key) {
int i;
char keyPrime[BIG];

strcpy(keyPrime, key);
strcat(keyPrime, "=");


for (i = 0; envArray[i] != NULL; i++) {
if (strstr(envArray[i], keyPrime) == envArray[i]) {
break;
}
}

return i;
}


// Don't screw with my return value...
const char* myGetEnv(const char** envArray, const char* key) {
int i;

i = envIndex(envArray, key);

if (envArray[i] == NULL) return NULL;
else return (envArray[i]+strlen(key)+1);
}


void printenvMulti(const char* key) {
char* s;

s = myGetEnv(_environ, key);
if (s == NULL) printf("%s is not in _environ\n", key);
else printf("myGetEnv(_environ, \"%s\") --> %s\n", key, s);

s = myGetEnv(environ, key);
if (s == NULL) printf("%s is not in environ\n", key);
else printf("myGetEnv(environ, \"%s\") --> %s\n", key, s);

s = getenv(key);
if (s == NULL) printf("%s is not available to getenv()\n", key);
else printf("getenv(\"%s\") --> %s\n", key, s);
}


int main(int argc, char** argv) {
assert(argv[1] != NULL);

printenvMulti(argv[1]);
return 0;
}
----------------------------------------------------------------------

--
Milton L. Hankins \\ ><> Ezekiel 18:21 ><>
Software Engineer, Raytheon Systems Company // <mlh@swl.msd.ray.com>
http://amasts.msd.ray.com/~mlh \\ RayComNet 7-225-4728
Environment inheritance under Windows NT 4, Attempt 2 [ In reply to ]
Works fine for me.
Use the same case for the python version.
> C:\>python -c "import os; print os.environ['WINDIR']"

--
--Darrell

Milton L. Hankins <mlh@swl.msd.ray.com> wrote in message
news:Pine.SGI.3.95q.990623204139.149495A-100000@masox202...
> Since I've not yet gotten a response to my first post, here's an
> elaboration.
>
> Windows NT Workstation 4.00.1381, SP5.
>
> 1. Right click on My Computer, choose Properties, Environment tab. Note
> the value of the System Variable "windir" and press Cancel. (On my
> system, this is "C:\WINNT".)
>
> 2. Open a Command prompt.
>
> 3. Here's a transscript of my CMD session, you can follow along:
>
> -----------------------------------------------------
> C:\>echo %WINDIR%
> C:\WINNT
>
> C:\>python -c "import os; print os.environ['windir']"
> C:\WINNT
>
> C:\>set WINDIR=foo
>
> C:\>echo %WINDIR%
> foo
>
> C:\>python -c "import os; print os.environ['windir']"
> C:\WINNT
>
> -----------------------------------------------------
>
> What is going on here? I wrote a program using VC5 to extract a variable
> (1) directly from environ and _environ and (2) by calling getenv(). All
> three reported "foo". (Source provided below.)
>
> After rummaging through the Python source, it appears that os.environ is
> provided through the posix module, which in turn gets the environment data
> from the "extern char** environ".
>
> Could this have something to do with Microsoft's run-time DLLs? I noticed
> that Cygwin B19 used to exhibit this behavior as well, but it seemed to go
> away in B20.1.
>
> Python picks up the environment correctly if I go into the Control Panel,
> System, Environment, and click OK. But I have to do this each time I log
> in to NT.
>
>
> ----------------------------------------------------------------------
> #include <stdlib.h>
> #include <stdio.h>
> #include <assert.h>
> #include <string.h>
>
> extern char** environ;
>
> #define BIG 80
>
>
> int envIndex(const char** envArray, const char* key) {
> int i;
> char keyPrime[BIG];
>
> strcpy(keyPrime, key);
> strcat(keyPrime, "=");
>
>
> for (i = 0; envArray[i] != NULL; i++) {
> if (strstr(envArray[i], keyPrime) == envArray[i]) {
> break;
> }
> }
>
> return i;
> }
>
>
> // Don't screw with my return value...
> const char* myGetEnv(const char** envArray, const char* key) {
> int i;
>
> i = envIndex(envArray, key);
>
> if (envArray[i] == NULL) return NULL;
> else return (envArray[i]+strlen(key)+1);
> }
>
>
> void printenvMulti(const char* key) {
> char* s;
>
> s = myGetEnv(_environ, key);
> if (s == NULL) printf("%s is not in _environ\n", key);
> else printf("myGetEnv(_environ, \"%s\") --> %s\n", key, s);
>
> s = myGetEnv(environ, key);
> if (s == NULL) printf("%s is not in environ\n", key);
> else printf("myGetEnv(environ, \"%s\") --> %s\n", key, s);
>
> s = getenv(key);
> if (s == NULL) printf("%s is not available to getenv()\n", key);
> else printf("getenv(\"%s\") --> %s\n", key, s);
> }
>
>
> int main(int argc, char** argv) {
> assert(argv[1] != NULL);
>
> printenvMulti(argv[1]);
> return 0;
> }
> ----------------------------------------------------------------------
>
> --
> Milton L. Hankins \\ ><> Ezekiel 18:21 ><>
> Software Engineer, Raytheon Systems Company // <mlh@swl.msd.ray.com>
> http://amasts.msd.ray.com/~mlh \\ RayComNet 7-225-4728
>
>
>
Environment inheritance under Windows NT 4, Attempt 2 [ In reply to ]
I suppose this could be a side-effect of the way our IT department sets up
NT. But I shudder to think how or what really causes it.

On Thu, 24 Jun 1999, Darrell wrote:

> Works fine for me.
> Use the same case for the python version.
> > C:\>python -c "import os; print os.environ['WINDIR']"

Thanks for the response. Unfortunately, this doesn't help. :( I tried
exact, all upper, and all lower case to the same result.

I've developed a workaround for posixmodule which uses getenv() under
Windows instead of direct access to environ. It works great. I had
really hoped others experienced this problem. Sigh. I will send my patch
to Guido anyway. Maybe it will be deemed worthy.


Fingers crossed...

--
Milton L. Hankins \\ ><> Ezekiel 18:21 ><>
Software Engineer, Raytheon Systems Company // <mlh@swl.msd.ray.com>
http://amasts.msd.ray.com/~mlh \\ RayComNet 7-225-4728
Environment inheritance under Windows NT 4, Attempt 2 [ In reply to ]
[Milton L. Hankins, has trouble with envar WINDIR in NT]

http://support.microsoft.com/support/kb/articles/Q100/8/43.asp

will tell you that WINDIR is "special". Not exactly clear how, though.
Best I can suggest is that you fight with NT until it delivers a correct
value for WINDIR as soon as you boot; you really shouldn't be messing with
this envar.

search-ms-support-for-"windir"-to-find-out-why-not<wink>-ly y'rs - tim
Environment inheritance under Windows NT 4, Attempt 2 [ In reply to ]
"Milton L. Hankins" wrote:
>
> Since I've not yet gotten a response to my first post, here's an
> elaboration.
>
> Windows NT Workstation 4.00.1381, SP5.
> C:\>echo %WINDIR%
> C:\WINNT
>
> C:\>python -c "import os; print os.environ['windir']"
> C:\WINNT
>
> C:\>set WINDIR=foo
>
> C:\>echo %WINDIR%
> foo
>
> C:\>python -c "import os; print os.environ['windir']"
> C:\WINNT
>
> -----------------------------------------------------

I don't get this behavior on NT 4.00.1381. This was copied from
cmd.exe:

N:\python\Python-1.5.2\PCbuild>ver

Windows NT Version 4.0

N:\python\Python-1.5.2\PCbuild>./python -c "import os; print
os.environ['WINDIR']"
C:\WINNT35

N:\python\Python-1.5.2\PCbuild>set WINDIR=foo

N:\python\Python-1.5.2\PCbuild>echo %WINDIR%
foo

N:\python\Python-1.5.2\PCbuild>./python -c "import os; print
os.environ['WINDIR']"
foo

N:\python\Python-1.5.2\PCbuild>

I think I am at service pack 4. I am using Python 1.5.2. What is your
Python version (not that it should matter). Very peculiar.

The code seems to be getting the environment from char **environ. The
VC 6.0 docs say to use _environ, and I don't see a reference to
_environ.
The docs also say getenv() uses _environ.

Although I can't duplicate the behavior you describe, it seems to
me Python should be using _environ instead of environ. Does anyone
know what environ is on NT? I see "#define environ _environ" in
stdlib.h, but it is inside a bunch of #ifdef's.

Jim Ahlstrom
Environment inheritance under Windows NT 4, Attempt 2 [ In reply to ]
The mystery has been solved. It turns out that my environment has a
duplicate name problem -- that is, two entries for the environment
variable exist in the data structure, each with two different values. This
can be easily be verified by writing a C program to print the contents of
_environ. (I have such a program if anyone is interested.)

This is not entirely the fault of Windows NT. On my system, the
environment is being tainted by another appliacation. However, NT is
permitting this to take place. Feh.

Thus, an environment variable lookup becomes dependent on the
implementation's ordering. In Python's implementation, the last entry
wins because it slurps the data from (C) _environ and stores it in
posix.environ. The command prompt and getenv() seem to always get the
"right" value, somehow.

--
Milton L. Hankins \\ ><> Ezekiel 18:21 ><>
http://www.snurgle.org/~mhankins // <mlh@swl.msd.ray.com>
These are my opinions, not Raytheon's. \\ W. W. J. D. ?