Vincent Lefevre wrote:
> The problem is that when Mutt or run-mailcap is run, the value of
> $DISPLAY (and $XAUTHORITY) may be incorrect, and it is unavoidable.
> The reason is that these environment variables are inherited when
> the process is started, and when a new X session is started, the
> values of these variables are no longer valid (they no longer
> reflect the parameters of the X session), and an external process
> can't change their values to correct them.
Yes, this problem rears its head any time a long-lived commandline
utility wants to launch an X application. If the Wayland developers
get their way, it may apply to some graphical utilities in the future,
too. :) The fundamental thing is that screen has no way to modify the
environment of attached programs.
All the thorough fixes I can imagine for this are offensively ugly:
a. screen could ptrace its clients and inject environment variables.
b. an LD_PRELOAD hack initiated by screen could inject environment
variables at some suitable time (exec, say).
c. programs likely to be run through screen could implement some
specification for modifying the environment when reattached
or when launching X apps (for example by running a special
wrapper or linking to some special library).
d. X clients could start interpolating variables in the value of
DISPLAY and XAUTHORITY, to make configurations like
XAUTHORITY='$HOME/.Xauthority' possible.
At first glance, (d) looks unoffensive, but it's kind of hard to
change the X client libs on remote systems. I don't know what the
right thing to do is.
If I understand correctly, this bug is, roughly speaking, about (c).
The specs in question would be the mailcap spec and the implementation
of xdg-open. It wouldn't help with programs that try to run
x-terminal-emulator without a mailcap file to tell them how, but after
looking at the alternatives, it does start to look nice by comparison.
:)
Cc-ing the screen maintainers in case they know a clean approach we've
missed.
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
