不能修改父进程环境

实际上，除了应用程序本身，没有应用程序可以改变任何进程的环境，并且导出的值只会在子进程生成时被子进程继承。如果你对内核编程有足够的了解来打破这个老生常谈，那么你就不需要问这个问题。这意味着，出于您的目的，您不能将变量从子shell或派生进程导出到父进程，也不能更改已经派生的子进程的环境。

帮助其他进程修改自身环境

所以，你不能直接做你想做的事。句号。
然而，如果你设计你的程序，你可以让他们从一个文件或文件描述符读取定期或当信号，然后你可以编辑文件从你的衍生进程的期望，有时会导入这些值。
例如，如果你有一个Bash程序，如：

while true; do
    source new_env.sh
    # do something with new values
    sleep 5
done

字符串
然后每隔5秒，循环将导入 new_env.sh 文件，其中定义的任何导出、命令或变量将成为当前执行环境的一部分。您还可以为SIGUSR 1或SIGUSR 2定义一个陷阱，以便在接收到信号时读取 new_env.sh，然后重新读取文件。
Ruby可以做同样的事情。您可以定义修改当前环境的 ENV 的陷阱和循环，这将影响从该点产生的任何子进程。您还可以序列化环境变量或其他数据，并将它们写入其他应用程序可以读取的位置。作为一个关键的区别，这不允许Bash或Ruby直接修改另一个进程的环境;它只是一种允许另一个进程修改自己进程间通信的形式。

注意事项和安全问题

在运行时源文件是一个巨大的安全风险，通常不建议。你得到了一个可行的答案，但它很可能解决了错误的问题。最有可能的是，您应该从架构的Angular 来看待这一点，而不是将其作为您需要找到的工程工作区。

运行时阅读配置文件示例

更一般地说，在长时间运行的程序中修改值的正确方法是从可信的源 *（如数据库或权限控制的配置文件）读取白名单中的值 *，然后在运行时 * 清理输入 *。例如，你可以让你的Ruby脚本做如下事情：

require "yaml"

# read file containing a serialized Ruby Hash
# such as {:foo=>1, :bar=>2, :baz=>3}
def config
  # read in your key/value store
  cfg = YAML.load_file "config.yml"

  # limit allowed values for Hash;
  # non-whitelisted values like :quux will
  # be ignored
  whitelist = %i[foo bar baz]

  @config.map do |key, value|
    # only process whitelisted keys, and sanitize
    # the values; in this case, that means coercing
    # them to Integer rather than accepting arbitrary
    # values
    cfg[key] = value.to_i if whitelist.keys.include? key
  end

  # re-export whatever you now have in @config, and then
  # return the Hash
  @config.map { ENV[_1] = _2 }
end
  
loop do
  config
  # spawn a process, send a signal, or use IPC
  # to communicate with something else
  sleep 5
end

型
这是一个简单的例子，并不意味着是一个防弹或理想的解决方案。然而，它应该给予你一个如何相对安全地做到这一点的总体思路，前提是你可以控制你的配置文件，你的白名单，你把所说的文件的内容视为污染，并确保你在使用它们之前清理和验证你从中读取的任何值。
不管你用什么语言做这个。你可以使用Ruby、Bash、Zsh或其他你喜欢的东西。但是，一般原则是相同的：don't source the configuration file;* 读取 * 它，只处理你认为安全的行和值。