36

I use GNU Screen constantly. But, I've been trying to figure out if there is someway to get X11 apps to forward over screen when I am ssh-ing (Is that a word?). Currently if I try to run 'gedit' through screen, it opens on my 'server' computer and not on my client. If I do the same outside of screen, then everything is fine. But I want everything to be fine when I use screen too!

Thanks!

PS: I have googled the problem and I see mention of xmove, but I can't seem to find the package that contains xmove on my ubuntu. (ubuntu 10.10)

Improve this question
1
  • I have no time to find a complete answer now, but you need some environment variables to be set correctly. You can probably find out which ones from looking at you environment outside screen.
    – JanC
    Oct 28, 2010 at 4:17

7 Answers 7

Reset to default
35

To manually do this, once you have SSHed in, but before you reattach to screen, check your DISPLAY environment variable:

echo $DISPLAY

Once you have re-attached to screen, explicitly set the environment variable:

export DISPLAY=:N.0

where :N.0 is what the echo showed before the attach. This won't be perfect, since some application may be expecting to talk to the Session D-Bus, which is a bit more complex to send over the SSH connection.

Improve this answer
5
  • 1
    Awesome! This seems to work for most apps. I'm trying to up my screen 'fu'. Do you have any ideas or can you atleast point me in the general direction of how I can automate this? Thank you!
    – Sandro
    Oct 28, 2010 at 22:17
  • I've done weird things like scripting something like: echo $DISPLAY > $HOME/.display.txt; screen -x -d and then another in screen to run that does export DISPLAY=$(cat $HOME/.display.txt)
    – Kees Cook
    Oct 29, 2010 at 2:43
  • that's exactly what I've been trying to accomplish. But so far no luck. Trying to get that export to happen is quite the hurdle since running it in a script is no good, I need to somehow source it... and setenv also doesn't seem to have the magic touch either.
    – Sandro
    Oct 30, 2010 at 21:45
  • To source the script type . /path/to/script where script is export DISPLAY=$(cat $HOME/.display.txt)
    – Kees Cook
    Oct 30, 2010 at 22:15
  • This assumes you don't have screen auto-start on login (a la byobu)
    – A Student at a University
    Sep 27, 2011 at 13:46
14

there's a program called xpra in the repositories, it's like gnu screen for x11. it's not too hard to work with:

X Persistent Remote Applications

Xpra gives you the functionality of GNU Screen for X applications.

It allows the user to view remote X applications on their local machine, and disconnect and reconnect from the remote machine without losing the state of the running applications.

Improve this answer
3
  • 2
    I have written about how to actually integrate xpra with Screen to achieve both console and X11 application persistence: krlmlr.github.io/integrating-xpra-with-screen . Works for me.
    – krlmlr
    Mar 14, 2014 at 9:15
  • 1
    @krlmlr your link is broken
    – Brent
    Apr 29, 2020 at 16:16
  • 1
    @Brent: Thanks. I should bring it back. For the problem here, my solution stopped working eventually, and I never had the time or urgency to investigate.
    – krlmlr
    Apr 30, 2020 at 2:41
7

Byobu automatically reattaches ssh and gpg agents. I could make it reattach the display variable to, if that's helpful to you...

Improve this answer
2
  • It doesn't seem to even pass along the display variable in NEW sessions created in an ssh session with X11 forwarding. It would be wonderful if it did... I've stopped using it because of the headache of having to disable auto-starting byobu so that one can use the X11 forwarding.
    – A Student at a University
    Sep 27, 2011 at 13:42
  • Was this implemented? I'd like to try it if it has.
    – Brent
    Apr 30, 2020 at 14:31
2

This is how I got it working when running byobu

Add this line in .bash_login before the "_byobu_source.." line:

echo $DISPLAY > $HOME/.display.env

And then add this line to .bashrc:

if [ ! -z ${SSH_CONNECTION+x} ]; then
  export DISPLAY=$(cat $HOME/.display.env) 
fi
Improve this answer
0
1

It seems that the problem is that the environment variable XAUTHORITY is not preserved in the screen session. I solved this by adding the following to my .bashrc. I didn't think this should be necessary but I guess you do what you must:

# ensure X forwarding is setup correctly, even for screen
XAUTH=~/.Xauthority
if [[ ! -e "${XAUTH}" ]]; then
 # create new ~/.Xauthority file
 xauth
fi
if [[ -z "${XAUTHORITY}" ]]; then
 # export env var if not already available.
 export XAUTHORITY="${XAUTH}" 
fi

I don't expect this to be the best solution, or the most concise, but it works.

Improve this answer
0

FreeNX is a wonderful app for working with remote displays.

Improve this answer
1
0

Based on @harre suggestion, I found this to be the best working solution, at least for RHEL via Putty. I know there's a better way than to create a file that holds the var, but this works out of the gate to get X11 to have access to the DISPLAY when loaded via gnu screen.

Automated Solution

Add to .bashrc (or .bash_profile, depending on your use case)

#.bashrc
if [ -f ~/etc/.bash-screen-x11 ]; then
   echo $DISPLAY > $HOME/.display.env
   source ~/etc/.bash-screen-x11
fi

Then add the following file(or your path choice)

#~/etc/.bash-screen-x11
# sets back display var.
if [ -z $STY ]; then
  export DISPLAY=$(cat $HOME/.display.env)
fi
Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.