> And what if DISPLAY does not point to the
> wrong host:server.screen?
Good point. Perhaps black really is white,
and up really is down. But I doubt it.
The info from the questioner is vague and
incomplete, but, as I understand / assume /
conjecture what's happening here, lysithea =
lysithea.mdx.ac.uk, and that's the Tru64
system, not the laptop with the X server.
So, I conclude that any DISPLAY which uses
lysithea:0 for its host:server part must be
wrong.
I don't have a laptop running Exceed, but I
do have a Sun Solaris workstation, and when
I use "ssh -X" to connect from it to another
system, I get results like the following.
To a Tru64 system:
sol> ssh -X urtx
[...]
HP Tru64 UNIX V5.1B (Rev. 2650); Mon Feb 19 11:57:07 CST 2007
No mail.
urtx> echo $DISPLAY
urtx.antinode.info:10.0
To an HP-UX (11.11) system:
sol> ssh -X dy
[...]
Value of TERM has been set to "xterm".
dy $ echo $DISPLAY
10.0.0.39:10.0
where 10.0.0.39 is the IP address of "dy",
the HP-UX system.
So, I conclude that a typical sshd sets up
a virtual X server at server_host:10.0 (and
it even seems to work around here).
The questioner reported that his DISPLAY was
"lysithea.mdx.ac.uk:0.0". To me, this does
not appear to be consistent with his claim
that he had "set the X11 tunnelling with
[his] ssh session". Based on the results of
my tests, I'd expect it to be something like
"lysithea.mdx.ac.uk:10.0".
I've tried to guess who set DISPLAY to the
reported value, but so far I've learned
nothing about it. My guess is still that
it's something in the user's shell start-up
script(s), but my psychic powers are too weak
to tell me more.
I have code in my own "~/.profile" which
looks at the output of "who am i", and uses
it to set DISPLAY, but it's inside a test
like this:
if [ -z "$DISPLAY" ]; then
[...]
fi
so, if someone else (like, say, sshd) sets
DISPLAY for me, I don't whack its (good)
DISPLAY definition with my (bad) DISPLAY
definition.
> May be rebooting may fix it.
The X Window System is not Microsoft Windows,
so I doubt it.
