Vernon Cole wrote: > > Similarly, it seems that getenv() and putenv() should be inverse > functions, but they are not. os.getenv() refers to the parent > environment, os.putenv() refers to the child environment.
No, no, no! That's not true at all! BOTH of those functions refer to the environment of the CURRENT PROCESS. I inherited my environment from my parent process (which is often a shell). I can change my environment as much as I wish. When I create new processes, those processes inherit my current environment, with whatever changes I made. I can't change my parent's environment, and I can't change my children's environment. I can only hand off a copy of my environment to my children, which they are free to modify themselves. > We have established that there is no (documented) inverse function for > getenv() -- although shells do it somehow. We have not established that at all! getenv() gets from the current process environment, and putenv() modifies the current process environment. When you type a "set" command in a command shell, that executes inside bash (or cmd.exe or sh or whatever). In handling "set", bash calls putenv, which modifies bash's environment. Bash can see that change, of course, and any future processes that bash spawns will include those changes. > Is there an inverse for putenv() so that I can see what my children > will see? Of course you can! If YOU call putenv(), then YOU can call getenv() and see the changes you made to your environment. However, when you exit, all of your changes evaporate with your process. The parent process, whatever it is, continues to exist with the environment it had before. -- Tim Roberts, t...@probo.com Providenza & Boekelheide, Inc. _______________________________________________ python-win32 mailing list python-win32@python.org http://mail.python.org/mailman/listinfo/python-win32
