Proposal for addition of a new Process.environ property returning the environment variables registered by a process, possibly as a dictionary.

On Windows this seems to be painful to determine although still possible: http://www.codeguru.com/forum/archive/index.php/t-416841.html

Ugh, this is just as ugly as determining the cmdline was, it uses basically the same method and will likely suffer from the same reliability problems we're seeing there.

Removing 0.1.3 milestone

I'm the guy who helped you with the command line retrieval on Windows. Please ignore those CreateRemoteThread idiots. Take a look at this code (function PhGetProcessEnvironmentVariables):

http://processhacker.svn.sourceforge.net/viewvc/processhacker/2.x/trunk/ProcessHacker/native.c?revision=HEAD&view=markup

Just for the record when we'll reconsider this, Linux code was committed as r406 and removed in r464 and r599.

On FreeBSD we can use kvm_getenvv(): http://fuse4bsd.creo.hu/localcgi/man-cgi.cgi?kvm_getenvv+3

Issue 247 has been merged into this issue.

Another article about Windows: http://www.codeproject.com/Articles/25647/Read-Environment-Strings-of-Remote-Process

Reopening as I have a partial working patch for Windows. I'd like to have this ready for 0.5.0.

Linux implementation readded as r1259. Windows implementation added as r1260.

kvm_getenvv() on FreeBSD can only be used if /proc filesystem is mounted (and it's not by default). Partial implementation is below but I guess we better off not supporting FreeBSD at all.

static PyObject* get_process_environ(PyObject* self, PyObject* args) { long pid; char **env; struct kinfo_proc *pinfo; int num; static kvm_t **kd;

if (! PyArg_ParseTuple(args, "l", &pid)) {
    return NULL;
}

kd = kvm_open(NULL, NULL, NULL, O_RDONLY, NULL);

pinfo = kvm_getprocs(kd, KERN_PROC_PID, pid, &num);
if (pinfo == NULL) {
    return PyErr_SetFromErrno(PyExc_OSError);
}

env = kvm_getenvv(kd, pinfo, 9086);
if (env == NULL) {
    return PyErr_SetFromErrno(PyExc_OSError);
}

return Py_BuildValue("i", 33);

}

I fixed the heap corruption issue happening with the get_process_environ() call on windows in r1297

Great! Thanks.

Looking back at this I start to doubt the usefulness for two reasons:

• on Linux this seems to work just fine but if the environment of the process is modified the change is not propagated:

p = psutil.Process(os.getpid()) os.putenv('XXX', '1') 'XXX' in p.get_environ() False

• on Windows this can be used for the current process only; for all other processes, including the ones owned by the current user, we get an AccessDenied exception - also, if the environment of the current process is changed we also get AccessDenied.

That said, it probably make sense to give up on this. I'm going to leave this open for a while a take a definitive decision later.

More info about Linux not updating /proc/PID/environ: http://serverfault.com/questions/66363/environment-variables-of-a-running-process-on-unix/79463#79463

Ok, I'm still inclined to remove this due to the unreliabilities explained above for both Windows and Linux. Removal done in r1366 and closing this out as WontFix.

Comment deleted

Updated csets after the SVN -> Mercurial migration: r406 == revision 3e6905e0c623 r1260 == revision a299e2431879 r1297 == revision e278f365986c r1366 == revision b1dd9bd9ba25