Question about envvars
rceci at my-deja.com
rceci at my-deja.com
Mon Jun 7 15:50:07 EDT 1999
Stephen,
Boy I was excited to get a reasonable explaination so quickly, but alas,
it still does not work. Here is my test script:
#!/usr/local/bin/python
import MDIreg
reg = MDIreg.FileRegistry(1,1)
reg.exportEnvVars()
import os
print "child has it : "
os.system("env | grep MDI_REG_VERSION")
print "but do I have it? :"
print os.environ['MDI_REG_VERSION']
---
I am interested in this "MDI_REG_VERSION" envvar which gets exported by
my library. Here is the output:
child has it :
MDI_REG_VERSION=10.0
but do I have it? :
Traceback (innermost last):
File "regtest.py", line 12, in ?
print os.environ['MDI_REG_VERSION']
File "/usr/local/lib/python1.5/UserDict.py", line 12, in __getitem__
def __getitem__(self, key): return self.data[key]
KeyError: MDI_REG_VERSION
Any other ideas? Any way to tell the os/posix module to "refresh"?
By the way, thanks for the library implementation suggestion, but I must
keep it the way it is, because other c, and c++ (at the class level)
programs access this library.
Thanks
Rob
In article <375BFE38.3FB3E83C at ix.netcom.com>,
"Stephen J. Turner" <sjturner at ix.netcom.com> wrote:
> Hi Rob,
>
> > I have built a shared module that reads flat files for environment
> > variable information, and makes subsequent putenv calls for those
> > pertinent ones. This functionality is encapsulated in a c++ class,
> > FileRegistry, which I think I have working correctly, using shadow
> > classes under python. All I expose in the class is the ctor, the
dtor,
> > and the method called exportEnvVars():
> >
> > %module MDIreg
> > %{
> > #include "fileregistry.h"
> > %}
> >
> > class FileRegistry
> > {
> > public:
> > FileRegistry(bool, bool);
> > ~FileRegistry();
> > void exportEnvVars();
> > };
> >
> > ...
> >
> > However, I can't seem to get the envvars to persist into the current
> > process space. If I fork off a child, then I can see the envvars
that I
> > expect.
>
> The problem is that, although putenv does indeed modify the current
> process's environment, Python only reads the environment when the
posix
> module (imported by os) is first imported, so as to create the environ
> dictionary. (Try confirming this behavior by postponing "import os"
> until after your call to MDIreg.exportEnvVars. You should see your
> environment changes reflected in os.environ.)
>
> The proper solution is, I think, to avoid the direct use of the putenv
> function, and instead to use the Python C API to modify the os.environ
> mapping (which calls putenv as a side effect). Here is a crude C
module
> to do just such a thing:
>
> -------------------- START modenv.c --------------------
> #include <Python.h>
>
> #include <stdio.h>
> #include <string.h>
>
> static PyObject *modenv_load(PyObject *self, PyObject *args)
> {
> FILE *fp;
> PyObject *os, *environ, *v;
> char buf[256];
> char *file;
> char *value;
>
> if (!PyArg_ParseTuple(args, "s", &file))
> return NULL;
>
> os = PyImport_ImportModule("os");
> environ = PyObject_GetAttrString(os, "environ");
>
> if (fp = fopen(file, "r")) {
> while (fgets(buf, sizeof(buf), fp), !feof(fp)) {
> /* skip lines that do not contain equals sign */
> if (!(value = strchr(buf, '=')))
> continue;
>
> /* remove trailing newline */
> buf[strlen(buf)-1] = '\0';
>
> *value++ = '\0';
> v = PyString_FromString(value);
> PyMapping_SetItemString(environ, buf, v);
> Py_DECREF(v);
> }
> fclose(fp);
> }
>
> Py_DECREF(environ);
> Py_DECREF(os);
>
> Py_INCREF(Py_None);
> return Py_None;
> }
>
> static struct PyMethodDef modenv_methods[] = {
> {"load", (PyCFunction)modenv_load, METH_VARARGS},
> {NULL, (PyCFunction)NULL, 0, NULL}
> };
>
> void initmodenv()
> {
> if (!Py_InitModule4("modenv", modenv_methods, NULL, NULL,
> PYTHON_API_VERSION))
> Py_FatalError("can't initialize module modenv");
> }
> -------------------- END modenv.c --------------------
>
> Hope it helps.
>
> Regards,
> Stephen
>
> --
> Stephen J. Turner <sjturner at ix.netcom.com>
>
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
More information about the Python-list
mailing list