X-Win32 Knowledge Base   >   X Clients and sessions are displaying on the wrong system

Search


About StarNet

StarNet Communications has been a leading developer of X Windows solutions since 1989. After establishing X-Win32 as the de facto standard in the higher education market during the early to mid-1990s -- 150 unlimited Campus Site Licenses worldwide -- X-Win32 has become of one the top three PC X servers in the government and commercial sectors as well.

Unlike its major rivals, Exceed (Hummingbird) and Reflection-X (WRQ/Attachmate), X-Win32 offers a highly focused PC X server that offers superior performance and productivity features, stability, ease of use and low cost (40% or better in most cases).

StarNet also delivers unequaled customer support. Our state-of-the-art engineering infrastructure allows us to fix problems and make a new release available quickly (overnight in many cases). As our testimonials page shows, StarNet customers consistently rate their X-Win32 experience as the best in the industry.




X Clients and sessions are displaying on the wrong system

X-Win32 sessions displaying on the wrong system generally indicate a problem with the $DISPLAY environment variable or with the -display command-line parameter being passed to applications such as xterm. This problem does not apply to all types of sessions that X-Win32 supports.

Connection methods susceptible to display on the wrong system

  • rexec, rsh – rexec and rsh sessions require that the -display argument be passed to the initial session command (e.g. xterm, dtterm, konsole, or gnome-terminal) and this initial session command then sets the $DISPLAY environment variable for subsequent commands
  • StarNetSSH without X11 Forwarding – Although rarely used in this way, StarNetSSH without X11Forwarding operates similarly to rexec and rsh as described above

    Connection methods not susceptible to display on the wrong system

  • StarNetSSH with X11 Forwarding (the default) – StarNetSSH with X11 Forwarding uses only localhost connections and automatically sets the $DISPLAY environment variable for all X Clients, including the initial session command; if there is a problem with a login or profile script overriding the $DISPLAY environment variable then the X Client will simply not display at all
  • Xdmcp – Xdmcp connections do not need the -display command-line parameter because there is no session command being executed; in addition, they set the $DISPLAY environment variable for the entine desktop system (e.g. CDE, Gnome, or KDE) that you are logging into so all clients started via menus will typically work (there may be a problem with clients started from applications that process login scripts, such as xterm, gnome-terminal, or konsole)

    Causes of the problem and solutions

  • Hard-coded address being passed in the session command to the -display command line parameter
    • Solution: Use the $DISPLAY session command variable instead of a hard-coded address (e.g. xterm -ls -display $DISPLAY). Note that in X-Win32 8 and later this session command variable is @DISPLAY@.
    • Solution: If you are hard-coding the address of your firewall to the Internet so that you can forward connections back to your machine behind the firewall, then use the $IPSMART:$DNUM session command variables to use IPSmart to obtain the address of your firewall automatically (e.g. xterm -ls -display $IPSMART:$DNUM)
    • Solution: Use StarNetSSH with X11 Forwarding instead
    • Your cshrc, bashrc, or profile scripts on the remote host are setting the $DISPLAY environment variable; this is typically the case at sites that have used UNIX exclusively for years and had previously hard-coded the address of each user’s machine into the login scripts
    • Solution: Remove the setting of the $DISPLAY environment variable from the login scripts
    • Soltuion: Develop a more sophisticated way to only set $DISPLAY when appropriate and to not set it when connecting via X-Win32
    • The Proxy option on X-Config’s Display form is selected and specifies the address of another machine running an X Server
    • Solution: Select one of your local IP addresses in X-Config’s Display tab instead of Proxy


How Can We Improve This KB Article?

Please rate the quality of this article: Excellent Good Fair Poor

Did this article answer your question? If not, we'd like to hear more about it:

Do you need additional assistance? If so, enter your email address:

Articles are periodically updated based on your feedback. If you enter an email address, then you will be given the opportunity to open a case, for which you will receive a response within 2 business days.