In this specific case, instead of letting Gnome run
dbus-launch to create a random D-Bus address, start
dbus-daemon explicitly early in your X session startup and give it a fixed address like
Given the information in the bug report, you may even be able to get away with
unset DBUS_SESSION_BUS_ADDRESS and let applications find out the bus address from the root window properties.
In the general case, your assessment is correct: all you have is unreliable methods such as
ptrace (which may crash the program, or not work due to a security framework such as Apparmor or SELinux) or injecting a shell command (which only works in panes that are currently at a shell prompt). Running a command at each shell prompt (with zsh's
preexec or bash's
PROMPT_COMMAND) at least doesn't risk breaking stuff.
Another solution would be an
LD_PRELOAD library that intercepts
getenv calls. This also feels like overkill.
Your best bet is to let the application do the job by creating a level of indirection: arrange for the value of the environment variable to remain valid, and for the application to interpret it in a situation-aware manner. Letting the application look up the D-Bus bus address in the root window properties is an example of this approach.