Linux上的Python环境变量

Suf*_*ian 13 python gdb environment-variables

Python对环境变量的访问并不能准确反映操作系统对进程环境的看法.

在特定情况下,os.getenv和os.environ没有按预期运行.

有没有办法正确地获得正在运行的进程环境?


为了证明我的意思,拿两个大致相同的程序(第一个在C中,另一个在python中):

#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
int main(int argc, char *argv[]){
    char *env;
    for(;;){
        env = getenv("SOME_VARIABLE");
        if(env)
            puts(env);
        sleep(5);
    }
}
Run Code Online (Sandbox Code Playgroud)
import os
import time
while True:
    env = os.getenv("SOME_VARIABLE")
    if env is not None:
        print env
    time.sleep(5)
Run Code Online (Sandbox Code Playgroud)

现在,如果我们运行C程序并使用gdb附加到正在运行的进程并通过执行以下操作强制更改引擎环境:

(gdb) print setenv("SOME_VARIABLE", "my value", 1)
[Switching to Thread -1208600896 (LWP 16163)]
$1 = 0
(gdb) print (char *)getenv("SOME_VARIABLE")
$2 = 0x8293126 "my value"
Run Code Online (Sandbox Code Playgroud)

那么前面提到的C程序将每5秒开始喷出一次"我的价值".然而,前面提到的python程序不会.

在这种情况下,有没有办法让python程序像C程序一样运行?

(是的,我意识到这是一个在运行过程中执行的非常模糊且可能具有破坏性的操作)

此外,我目前正在使用python 2.4,这可能已在更高版本的python中修复.

dda*_*daa 14

这是一个非常好的问题.

事实证明,os模块初始化os.environ为在解释器启动时设置的值.换句话说,标准库似乎不提供对getenv函数的访问.posix.environ

这种情况下,在unix 上使用ctypes可能是安全的.因为您将调用超标准的libc函数.


Gly*_*yph 11

您可以ctypes非常简单地使用它:

>>> from ctypes import CDLL, c_char_p
>>> getenv = CDLL("libc.so.6").getenv
>>> getenv.restype = c_char_p
>>> getenv("HOME")
'/home/glyph'
Run Code Online (Sandbox Code Playgroud)