Starting an X11 client on another machine, without ssh

Bill Freeman f at ke1g.mv.com
Wed Mar 24 15:57:36 EDT 2010


Below are a working pair of scripts, should anyone find them useful.

I would have attached, rather than included them, but if the MV webmail
interface lets me attach files, I haven't figured out how.

These work for my current application.

sxon lives on the PATH on my machine with the X server (ubuntu running
on my wimpy laptop), call it "host".  xhere lives in the
/home/username/remote_scripts
directory on the client machine (CentoOS VM on the same laptop, without
X server of its own), which is in my /etc/hosts as guest.

Back on host, if I run "sxon usernam at guest", I get an xterm running
on the guest, but displaying on the host X server.  The sxon command
completes, the xterm runs.  Or "sxon username at guest emacs" gets me an
emacs running on guest and displaying on host.  "emacs" isn't
specially known.  You can pass the sxon command the name (or path to)
any X aware application.  These can be added to menu's on the host
system so that I can start an emacs on the guest with the host window
manager.

Sadly, you can't say "sxon username at guest ls" because ls expcts to output
to stdout, and that's redirected to /dev/null.  As I mentioned in a
previous post, without the redirections, the command being run in the
background on the guest holds the pseudo-tty open and the ssh command on
host does not complete (until the backgrounded command exits). 

Redirection also causes a problem if you specify a non-existent command,
since, apparently, bash's "command not found" message gets eaten by the
redirection.  That's the reason for the "which" tomfoolery.

[Anyone with suggestions about the redirection issues, please speak up.]

In my VM the account name is different from my account name on my laptop.
If they were the same I could leave off the "username@" for all the commands.

If your client is running sshd on a port other than 22, you can append it
after a colon, e.g.;  "sxon foo at bar:9822".


A shortcoming is that if the DISPLAY variable is complex on the host,
the guest probably won't get it right.  (This would mean a chain of being
xon'ed to one machine, and xon'ing from there to a third machine.)


The holy grail would be to be able to push the necessary shell commands
through the ssh command argument, rather than needing to have xhere
installed somewhere.

This is more shell coding than I've done in maybe a decade.  If someone
knows a better way to break stuff into an array than the read -ra trick,
I'd like to hear it.

Bill


sxon:
-------------------------------------------------------
#!/bin/bash

userhost=${1/:/ }
port='22'
cmd=$2

read -ra a <<< $userhost

if [ ${#a[@]} -gt 1 ]; then
  userhost=${a[0]}
  port=${a[1]}
fi

host=${userhost/@/ }

read -ra a <<< $host

if [ ${#a[@]} -gt 1 ]; then
  host=${a[1]}
fi

if [ -z $cmd ]; then
  cmd='xterm'
fi

xhost +$host
ssh -p $port $userhost '$HOME/remote_scripts/xhere '"$DISPLAY $cmd"
------------------------------------------------------

xhere:
--------------------------------------------------------
#!/bin/bash

read -ra x <<< "$SSH_CLIENT"
export DISPLAY=${x[0]}$1

# For the path setup and possibly other environment variables.
# This means .bashrc will be read twice, but that shouldn't hurt.
if [ -f ~/.bash_profile ]; then
  . ~/.bash_profile
fi

err=`which $2 2>&1`
if [ $? -ne 0 ] ; then
  echo $err 1>&2
  exit
fi

# Until stdin, stdout, and/or stderr is closed, the pseudo tty doesn't
# close, sshd doesn't close, and the ssh command on the other end
# doesn't end.
$2 < /dev/null > /dev/null 2>&1 &
--------------------------------------------------------


More information about the gnhlug-discuss mailing list