The interactions between the environment settings (target.env-vars,
target.inherit-env) and the inferior life-cycle are non-obvious
today. For example, if target.inherit-env is set, the target.env-vars
setting will be augmented with the contents of the host environment
the first time the launch environment is queried (usually at
launch). After that point, toggling target.inherit-env will have no
effect as there's no tracking of what comes from the host and what is
a user setting.
This patch computes the environment every time it is queried rather
than updating the contents of the target.env-vars property. This
means that toggling the target.inherit-env property later will now
have the intended effect.
This patch also adds a target.unset-env-vars settings that one can
use to remove variables from the launch environment. Using this, you
can inherit all but a few of the host environment.
The way the launch environment is constructed is:
1/ if `target.inherit-env` is set, then read the host environment into the launch environment. 2/ Augment the launch environment with the contents of `target.env-vars`. This overrides any common values with the host environment. 3/ Remove for the environment the variables listed in `target.unset-env`.
The one functional difference here that could be seen as a regression
is that target.env-vars will not contain the inferior environment
after launch. It's unclear that this is what any user would have
expected anyway, and we can make it clear(er) in the help that this
setting only contains the values specified by the user.
"passed to the process when launched"
might be clearer.