有没有办法改变Unix的另一个进程的环境variables？
在Unix上，有没有什么办法可以让一个进程改变别人的环境variables（假设他们都是由同一个用户运行的）？ 一般的解决办法是最好的，但如果不是，那么一个是另一个的孩子的具体情况呢？
编辑：如何通过GDB？
通过gdb：
(gdb) attach process_id (gdb) call putenv ("env_var_name=env_var_value") (gdb) detach 这是一个非常讨厌的黑客行为，当然，只能在debugging场景中进行。
您可能可以在技术上做到这一点（请参阅其他答案），但可能无法帮助您。
大多数程序会期望在启动后不能从外部改变环境variables，因此大多数程序可能只是在启动时读取他们感兴趣的variables，并基于此进行初始化。 所以之后改变它们不会有什么不同，因为程序将不会重新读取它们。
如果你把这个作为一个具体的问题，你应该采取不同的方法。 如果只是出于好奇：好的问题:-)。
基本上没有。 如果你有足够的权限（root或者大约），并且在/ dev / kmem（内核内存）周围戳了一下，并且你对进程的环境做了修改，如果这个进程实际上事后重新引用了这个环境variables（也就是进程还没有拿过这个env var的副本，也没有使用这个副本），那么也许，如果你是幸运的，聪明的，风向正确，而且月相是正确的，你可能会取得一些成就
引用杰里皮克：
你不能教一个老狗新花样。
你可以做的唯一的事情是在启动它之前改变subprocess的环境variables：它得到父环境的副本，对不起。
有关详细信息，请参见http://www.unix.com.ua/orelly/unix/upt/ch06_02.htm 。
只是评论关于使用/ proc的答案。 在linux / proc下受支持，但它不起作用，即使你是root用户， 也不能改变/proc/${pid}/environ文件：它是绝对只读的。
我可以想到做这件事情的方法，而且不适用于任意的过程。
假设你编写自己的实现“char * getenv”的共享库。 然后，设置'LD_PRELOAD'或'LD_LIBRARY_PATH'env。 这样你的进程就可以在你的共享库预装的情况下运行。
这样，你将基本上控制'getenv'函数的代码。 那么，你可以做各种讨厌的技巧。 您的'getenv'可以查询外部configuration文件或SHM段以获取env vars的替代值。 或者你可以做正则expression式search/replace所请求的值。 要么 …
我不能想到一个简单的方法来做到这一点，任意运行的进程（即使你是根），重写dynamic链接器（ld-linux.so）短。
据我所知，并不如此。 真的，你试图从一个进程到另一个进程的通信，这需要IPC方法之一（共享内存，信号量，套接字等）。 通过这些方法之一接收到数据后，可以设置环境variables或更直接地执行其他操作。
或者让你的进程更新新进程的configuration文件，然后：
- 在新进程上执行kill -HUP重新读取更新后的configuration文件，或者
- 有进程检查configuration文件更新时不时。 如果发现更改，则重新读取configuration文件。
HTH。
干杯，
抢
如果你的Unix支持/ proc文件系统，那么阅读env就很简单了 – 你可以通过这种方式阅读环境，命令行和其他属性。 改变它…嗯，我可以想办法，但这是一个坏主意。
更一般的情况…我不知道，但我怀疑有一个便携式的答案。
（编辑：我原来的回答假设操作系统想读环境，不改变它）
UNIX充满了进程间通信。 检查你的目标实例是否有一些。 Dbus正在成为“桌面”IPC的标准。
我使用真棒客户端来更改Awesome窗口pipe理器中的环境variables，这是Lua代码的Dbus“发件人”。
不是一个直接的答案，但是… Raymond Chen只有一天有一个基于Windows的理论基础 ：
…虽然在debugging器的帮助下确实存在不支持的方式或者在debugging器的帮助下工作的方式，但是对程序性访问另一个进程的命令行没有任何支持，至less内核没有提供任何内容。 …
没有不跟踪你不需要的信息的原则的后果。 内核不需要获得另一个进程的命令行。 它将命令行传递给
CreateProcess函数，并将其复制到正在启动的进程的地址空间中，在GetCommandLine函数可以检索它的位置。 一旦进程可以访问自己的命令行，内核的职责就完成了。由于命令行被复制到进程的地址空间，所以进程甚至可以写入存储命令行的内存并对其进行修改。 如果发生这种情况，那么原来的命令行就会永远丢失。 唯一已知的副本被覆盖。
换句话说，任何这样的内核设施都可以
- 难以实施
- 潜在的安全问题
然而，最可能的原因就是这种设施的使用情况有限。
