Question

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);
    }
}

import os
import time
while True:
    env = os.getenv("SOME_VARIABLE")
    if env is not None:
        print env
    time.sleep(5)

现在，如果我们运行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"

然后前面提到的C程序将每5秒开始喷出一次“我的值”。但是，前面提到的python程序不会。

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

（是的，我意识到这是一个非常模糊且可能对正在运行的流程执行的潜在破坏行为）

另外，我目前正在使用python 2.4，这可能已在更高版本的python中得到修复。

Answer 1

这是一个非常好的问题。

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

在unix上使用ctypes可能是安全的。因为您将调用超标准的libc函数。

Answer 2

您可以使用ctypes完成此操作：

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

Answer 3

另一种可能性是使用pdb或其他一些python调试器，并在python级别而不是C级别更改os.environ。 Here's我发布的一个小方法，用于中断正在运行的python进程，并在接收到信号时提供对python控制台的访问。或者，只需在要中断的代码中的某个位置粘贴pdb.set_trace（）。在任何一种情况下，只需运行语句“import os; os.environ['SOME_VARIABLE']='my_value'”，就python而言应该更新。

我不确定这是否也会使用setenv更新C环境，因此如果你有直接使用getenv的C模块，你可能需要做更多的工作来保持同步。

Answer 4

我不相信许多程序期望外部修改其环境，因此在启动时加载传递环境的副本是等效的。你只是偶然发现了一个实现选择。

如果您看到所有启动设置值和程序中的putenv / setenv有效，我认为没有什么值得关注的。有更简洁的方法可以将更新的信息传递给正在运行的可执行文件。

Answer 5

查看Python源代码（2.4.5）：

Modules / posixmodule.c获取convertenviron（）中的environ，它在启动时运行（参见INITFUNC）并将环境存储在特定于平台的模块（nt，os2或posix）中
< / LI>
Lib / os.py查看sys.builtin_module_names，并从posix，nt或os2导入所有符号

所以是的，它会在启动时决定。 os.environ在这里不会有用。

如果你真的想这样做，那么最明显的方法是创建你自己的自定义基于C的python模块，getenv总是调用系统调用。

Linux上的Python环境变量

5 个答案: