Subject: FVWM: NUTS! Can't get rsh working.

From: Maxwell Spangler <[email-masked]>
Date: Thu, 14 May 1998 01:59:12 -0400 (EDT)

I'm on Linux, with, I believe, Fvwm2 2.0.45/46, and I can't get the most
basic UNIX networking applet to run:

I start X, start an xterm inside Fvwm2 and then execute manualy:

rsh -l maxwell toronto "/usr/bin/X11/xterm -display maxwax:0.0"

When run on system 'maxwax' It should: 
  execute rsh,
    rsh connects to toronto as user maxwell
    run /usr/bin/X1/xterm on toronto
    display a new xterm window on system maxwax's display.

This works fine, but when I attempt to place the same command within my
.fvwm2rc file, it hangs when I execute it.

Switching to another virtual console and performing a 'ps' shows two rsh
processes sitting there.  Killing them doesn't do anything, I have to kill
X or ALT-backspace to shut X down and restart.

What am I missing here?  I'm performing the same function on my SCO OS504
system at work with it's rcmd instead of 'rsh'--basically the same
thing--without any problems.

ANY suggestions greatly appreciated!

-----------------------------------------------------------------------------
Maxwell Spangler, Software Developer, Greenbelt, Maryland, USA!SouthparkKCKSAS!

--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: Guangyong Xu <[email-masked]>
Date: Thu, 14 May 1998 02:20:23 -0400 (EDT)

That does seem odd. I don't know why you could execute it successfully 
from command line but not in your .fvwm2rc file. When it freezes your
display, I don't think killing the rsh process will help. You may have 
to go to the machine 'toronto' and kill the 'xterm' process you
started there. 

What I don't understand is, why are you running xterm
on a remote system and displaying it to your local display? It would be
much simpler and faster to do something like:
	xterm -e "ssh -l maxwell toronto" in your .fvwm2rc file.
Unless you don't have xterm installed on your local LINUX system, I
really don't see the advantage in running one remotely. This is not a
solution to your problem, just an alternative. And I think 'ssh' is much
better to use in you case since it uses the secure X channel and sets 
your display automatically for you, and 'rsh' is actually something that
should not be used any more. 

-G.Xu

---

From: Brad Giaccio <[email-masked]>
Date: Thu, 14 May 1998 07:32:55 -0400 (EDT)

Well I can see the benifit in running it that way.  For example I work on
a sparc 2 and it takes a good 15 seconds to pop up a xterm on my machine,
but only takes 2 seconds to get the xterm up and give me a shell prompt on
one of the ultras in my subnet.

Now to answer your Maxwell's question the problem is that your quotes are
getting stripped off well before they are supposed to be.  The solution I
came up with is to use xrsh.  Which is a script that I picked up somewhere
along the way and that used to be distributed with X11R3 and R4.  The way
you use it is simple

xrsh machine 
or xrsh machine xcpustate 
or xrsh -l <username> machine <any xapp and args>
the only problem with it is you need to have a .rhosts file on the
destination machine because the script pipes all output to /dev/null

so in fvwm I have
Exec xrsh <machine>

so I'll attach the script and you can use it as you like.

Brad

> > ANY suggestions greatly appreciated!

--- There are two kinds of knowledge, you either know the answer or
			you know where to find it
		      -Kane, Johnson, and anonymous
#!/bin/sh

# Some System V systems don't understand the #! construct.  
#   If your system does understand it, put ": " at the beginning of the line.
#
XRSH_VER='xrsh version 5.8'
XRSH_RCS='$Header: /usr/u/jjd/xrsh/RCS/xrsh.sh,v 1.12 1994/06/13 15:53:11 jjd Exp $'
XRSH_TIME='Time-stamp: <94/06/13 11:43:59 jjd>'
#
# Copyright 1991 by James J. Dempsey <[email-masked]>
# 
# Permission to use, copy, modify, distribute, and sell this software and its
# documentation for any purpose is hereby granted without fee, provided that
# the above copyright notice appear in all copies and that both that
# copyright notice and this permission notice appear in supporting
# documentation, James J. Dempsey makes no representations about the
# suitability of this software for any purpose.  It is provided "as is"
# without express or implied warranty.
#
#
# xrsh:  start an X11 client on another host
#
# Usage: xrsh [-help] [-version ] [-l username] [-auth authtype] [-screen #] [-pass envlist] \
#	[-debug] [-debug2] hostname [X-command [arguments...]]
#
# Example usage: xrsh expo.lcs.mit.edu xterm
#
# Runs the given command on another host with $DISPLAY set in the environment.
#    Handles authentication using xhost, xauth, or $XAUTHORITY (or none).
#    Xrsh is very careful not to leave any extra processes waiting
#       around on either machine for the client to exit.  In order
#       to achieve this, csh is used on the remote host and all inputs
#       and outputs are redirected to /dev/null.
#    The -debug switch allows you to see errors, but doesn't worry about
#       leaving extra processes around.
#    The -debug2 switch sets -x so that you can see every command
#       executed by the script  (very verbose)
#    The -l switch allows you to use a different login name on the
#       remote host.  -l and its argument are passed directly to rsh.
#    The -help switch prints out the usage message.
#    The -screen switch allows you to start a client on a different screen.
#    If no X command is given, it defaults to xterm.  This means that
#         'xrsh remotehost' will start an xterm on remotehost.
#    If the given command is a path that ends in "xterm", it adds the 
#        arguments "-name xterm-$hostname" where $hostname is the name
#        of the remote host.  This allows you to customize your server's
#        xrdb database to set attributes, such as the window color, based 
#        on the name of remote host.  If you dislike this behaviour, specify
#        your own -name argument to xterm on the xrsh command line.
#
#    Xrsh handles authentication based on the value of $XRSH_AUTH_TYPE or
#        the value of the -auth command line switch.  The value can
#        be xhost, xauth, environment or none.  It defaults to xhost.
#             xhost -- run xhost to enable the remote host to open window
#                      run xhost on the host where the server is running
#             xhost-xterminal -- 
#                      run xhost to enable the remote host to open windows
#                      run xhost on the host where xrsh was first run
#             xauth -- merge the auth entry from this host on the remote
#                        host using xauth via rsh
#             environment -- pass the $XAUTHORITY environment variable from the
#                       local host to the remote host so that a common
#                       NFS accessable authority file can be used everywhere
#             none -- do nothing.  Assume the user has handled authentication.
#
#    If the environment variable XRSH_RSH_ERRORS is set to the name of a file, 
#        any rsh errors will appear in that file on the remote host.
#        If that variable is unset, error messages will be thrown away unless
#        the -debug switch is given. (Note: don't use ~ in the filename
#        because it will expand to ~ on the local host, but try to put the
#        errors in that file on the remote host.)    
#
#
#  COMMON PROBLEMS:
#     * Make sure your PATH environment variable on the remote host is
#           set in your .cshrc or .bashrc so that rsh programs have
#           access to it.  (/bin/sh and /bin/ksh users have a hard time
#           time here since their shells don't execute any init files
#           under rsh.  One way to do this is to use the XRSH_ENVS_TO_PASS
#           environment variable to pass PATH to the remote shell.
#           Optionally, you can type a full path to xrsh.
#           E.g.  xrsh remote-host /usr/bin/X11/xterm
#
#     * Make sure your PATH environment variable on the remote host
#           includes the directory containing the X programs.  This is 
#           often /usr/bin/X11 or /usr/local/bin/X11.
#     * Make sure you have rsh configured to work on the remote host.
#           You can test this by typing:  rsh remote-host echo '$PATH'
#           This will prove that rsh works and show you the PATH that
#           will be used on the remote host.  If you get "Permission 
#           denied." you probably need to update your ~/.rhosts file
#           on the remote host.  See rlogin(1).
#
# Until X11R5, this command used to be called "xon".  The name was
# changed in order to be more descriptive, to have a name that better
# matches its cousin (xrlogin) and to not collide with a similar command
# written by Keith Packard distributed with X11R5.
#
# ACQUIRING XRSH:
#
# Check for new versions of xrsh via anonymous ftp to ftp.x.org under the 
# contrib subdirectory.  Always do this before reporting a bug to see if 
# the bug has already been fixed.
#
# Written by Jim Dempsey <[email-masked]> with help from Stephen Gildea
#   <[email-masked]> based on an idea by Dave Mankins <[email-masked]>.
# Some additional features due to [email-masked],
#   "David B. Rosen" <[email-masked]>, Eero Simoncelli 
#    <[email-masked]> and  Martin Friedmann 
#    <[email-masked]>
#   Originally written around 1987.
#   Last modification by [email-masked].
#   Version 5.1 of xrsh was distributed with X11R5.

# initialize some variables

default_auth_type=xhost   # sites might want to change this
authenv=
foundarg=
progname=`basename $0`
rshoptions=""
passenvs=                # environment variables to pass along
xhostvar=                # used by auth type xhost-xterminal
usage="usage: $progname [-help] [-version] [-l username] [-auth authtype] [-screen #] [-debug] [-debug2] host [cmd [args ...]]"

if [ -z "$DISPLAY" ]; then
    echo "$progname: "'$DISPLAY must be set' 1>&2 ;
    exit 1
fi

if [ -z "$XRSH_RSH_ERRORS" ]; then
    XRSH_RSH_ERRORS=/dev/null
fi

# process command line arguments
until [ "$foundarg" = "no" ]
do
    foundarg=no
    case $1 in
	-version)
	    echo "Version: ${XRSH_VER}"
	    echo "RCS info: ${XRSH_RCS}"
            echo "Last saved: ${XRSH_TIME}"
            exit 0
	    ;;
        -debug)
            debug=t; foundarg=yes; shift;
            ;;
        -debug2)
            set -x; foundarg=yes; shift; 
            ;;
	-help)
            echo $usage; exit 0;
            ;;
        -l)
            shift; rshoptions="-l $1"; foundarg=yes; shift;
            ;;
	-auth)
            shift; XRSH_AUTH_TYPE=$1; foundarg=yes; shift;
            ;;
	-pass)
            shift; XRSH_ENVS_TO_PASS=$1; foundarg=yes; shift;
            ;;
        -screen)
            shift; 
            # this line was blatantly stolen from Keith Packard's xon
            DISPLAY=`echo $DISPLAY|sed 's/:\\([0-9][0-9]*\\)\\.[0-9]/:\1/'`.$1
            foundarg=yes;
            shift;
            ;;
    esac
done

if [ "$#" = "0" ]; then
    echo $usage 1>&2; exit 1;
fi

clienthost="$1"; shift      # The full remote host name (as full as possible)

command=$1
if [ -z "$command" ]; then  # default command to xterm if none specified
    command=xterm
else
    shift
fi

# Grab the arguments to the command here so that we don't have to worry
# about restoring them when doing IFS hacking below
xcmdargs="$@"

# Try to avoid running hostname.  
# Some shells set $HOST or $HOSTNAME automatically.
localhost=${HOST-${HOSTNAME-`hostname`}}           # The local host name

# Remove domain part from hostname.

# The following paragraph of IFS based code replaces sed and 
#    runs faster because it doesn't fork.
#       clientshort is remote host name without domain
#clientshort=`echo $clienthost | sed -e 's/\..*$//'` 
oldIFS=$IFS
IFS=.
set  $clienthost
clientshort=$1
IFS=$oldIFS

# Find display host

# The following paragraph of IFS based code replaces sed and 
#    runs faster because it doesn't fork.
#displayhost=`echo $DISPLAY | sed 's/:.*//'`
oldIFS=$IFS
IFS=:
set  $DISPLAY
case "$#" in
    1) displayhost=$localhost;;
    *) displayhost=$1;;
esac
IFS=$oldIFS

case "$displayhost" in
    "unix"|"local"|"")
        displayhost=$localhost;;
esac

# People use the -name resource to specify host-specific resources
# such as window color.
if [ `basename "$command"` = "xterm" ]; then
    command="$command -ls -sb -sl 3000 -name $clientshort -title '$clientshort'"
fi
if [ $# -ge 1 ]; then
    command="$command $xcmdargs"
fi

# Some System V hosts have rsh as "restricted shell" and ucb rsh is remsh
if [ -r /usr/bin/remsh ]; then
    rsh=remsh
elif [ -f /usr/bin/rcmd ]; then       # SCO Unix uses "rcmd" instead of rsh
    rsh=rcmd
else
    rsh=rsh
fi

# Construct the new $DISPLAY for the remote client

# The following paragraph of IFS based code replaces sed and 
#    runs faster because it doesn't fork.  It also handles the arp stuff.
# newdisplay="`echo $DISPLAY | sed \"s/^[^:]*:/${localhost}:/\"`"
oldIFS=$IFS
IFS=:
set  $DISPLAY
if [ $# = 2 ]; then 
    shift
fi
case "$clienthost" in
    # If the remote host is the localhost, then don't put the hostname
    #  in $DISPLAY and let X find the fastest display path
    "$displayhost")
        newdisplay=:$@
        ;;
    # if a full internet domain name is used, set $DISPLAY
    # using IP address so remote host will be guaranteed return path
    *.*)
        if [ -f /usr/etc/arp ]; then
            arp=/usr/etc/arp
        elif [ -f /etc/arp ] ; then
            arp=/etc/arp
        else
            arp=arp
        fi
        address=`$arp $displayhost |tr ')' '(' | awk  -F'(' '{print $2}'`
        if [ "$address" ]; then
            newdisplay="$address:$@"
        else
            newdisplay="${displayhost}:$@"
        fi
        ;; 
    # A host in the local domain
    *)
        newdisplay="${displayhost}:$@"
        ;;
esac
IFS=$oldIFS

# process env variables to pass early so that we can send them 
# in the xauth commands as well as the actual X client rsh command.
# This is necessary for brain-dead shells like ksh which don't run
# any init files to set the path properly.  The user can instead
# send PATH as an XRSH_ENVS_TO_PASS.
for variable in $XRSH_ENVS_TO_PASS
do
    if eval [ \""\${$variable-Xyzzy}"\" != "Xyzzy" ]; then
        eval passenvs="\"setenv $variable '\$$variable'; $passenvs"\"
    fi
done

# Use $XRSH_AUTH_TYPE to determine whether to run xhost, xauth, 
# propagate $XAUTHORITY to the remote host, or do nothing
case ${XRSH_AUTH_TYPE-$default_auth_type} in
  xhost)      
      if [ "$newdisplay" != "$DISPLAY" ]; then
      # If run on the same host as server, allow remote host access X server.
          if [ "$debug" ]; then
              xhost +@$clienthost
          else
              xhost +$clienthost > /dev/null 2>&1
          fi
      else
          # If run on a different host as the server, use rsh to allow
          #    access to the host in DISPLAY.
          xhostcmd="setenv DISPLAY $DISPLAY; exec xhost +$clienthost"

          if [ "$debug" ]; then
              # send $passenvs in case the user has a brain dead remote shell
              # and needs to be able to pass the PATH env var (e.g. ksh)
              echo "Executing \"xhost +$clienthost\" on $displayhost with DISPLAY=$DISPLAY"
              $rsh "$displayhost"  exec /bin/csh -cf "\"$passenvs $xhostcmd\"" < /dev/null
          else
              $rsh "$displayhost"  exec /bin/csh -cf "\"$passenvs $xhostcmd < /dev/null >& /dev/null\"" < /dev/null > /dev/null 2>&1
          fi
      fi
      ;;
  xhost-xterminal)
      # If run on an X terminal, rsh to the XDMCP host to run xhost
      # if this is the first time, we are on the XDMCP host and 
      # we can just run xhost.
      if [ "$XHOST" = "" ]; then
          xhostvar="setenv XHOST $localhost; "
          if [ "$debug" ]; then
              xhost +$clienthost
          else
              xhost +$clienthost > /dev/null 2>&1 
          fi
      else
          xhostvar="setenv XHOST $XHOST; "
          xhostcmd="setenv DISPLAY $DISPLAY; exec xhost +$clienthost"
	  # send $passenvs in case the user has a brain dead remote shell
          # and needs to be able to pass the PATH env var (e.g. ksh)
          if [ "$debug" ]; then
              echo "Executing \"xhost +$clienthost\" on $XHOST with DISPLAY=$DISPLAY"
              $rsh "$XHOST"  exec /bin/csh -cf "\"$passenvs $xhostcmd\"" < /dev/null
          else
              $rsh "$XHOST"  exec /bin/csh -cf "\"$passenvs $xhostcmd < /dev/null >& /dev/null\"" > /dev/null < /dev/null 2>&1
          fi
      fi
      ;;
  xauth)
      # the "xauth remove" is theoretically unnecessary below,
      # but due to a bug in the initial X11R5 (fixed in fix-09) xauth,
      # entries for MIT-MAGIC-COOKIE-1 get lost if
      # you do merge twice without the remove.  The remove
      # command can be removed when xauth gets fixed.
      if [ "$debug" ]; then
          xauth extract - $newdisplay | \
          $rsh $clienthost $rshoptions exec /bin/csh -cf "\"$passenvs xauth remove $newdisplay ; xauth merge -\""
      else
          # Conditionalize this on $passenvs so that we don't pay the price
          # of forking a csh on the remote host if we don't need environment
          # variables evaluated.
          if [ "$passenvs" ]; then
              xauth extract - $newdisplay | \
              $rsh $clienthost $rshoptions exec /bin/csh -cf "\"$passenvs xauth remove $newdisplay ; xauth merge -\"" >/dev/null 2>&1
          else
              xauth extract - $newdisplay | \
              $rsh $clienthost $rshoptions xauth remove $newdisplay \;xauth merge - >/dev/null 2>&1
          fi
      fi
      ;;
  none)
      ;;
  environment)
      authenv="setenv XAUTHORITY $XAUTHORITY; "
      ;;
  *)
      echo -n "$progname: "'$XRSH_AUTH_TYPE must be set to "xhost", ' 1>&2
      echo '"xhost-xterminal", "xauth", "environment" or left unset' 1>&2
      exit 1
      ;;
esac

# Do the real work using rsh.
# Don't use -n to rsh because SG IRIX doesn't support it.  
# Use < /dev/null instead.
if [ "$debug" ]; then
    echo "Executing \"$command\" on $clienthost with DISPLAY=$newdisplay"
    $rsh $clienthost $rshoptions /bin/csh -cf "\"setenv DISPLAY $newdisplay; $authenv $xhostvar $passenvs $command\"" < /dev/null
else
#
# The redirection inside the innermost quotes is done by csh.  The outer
# redirection is done by whatever shell the user uses on the remote end.
# The inner redirection is necessary for an error log -- the outer 
# redirection is necessary to make sure that the local rsh doesn't hang around.
#
# The outermost < /dev/null is to simulate the -n argument to rsh which 
# we don't want to use for portability reasons.
#
# The three sets of redirections are for the local shell, the login shell
# on the remote host and the csh on the remote host.
#
# We would like the last '>' to be '>&' or equivalent, but that would make this
# code dependent on what flavor of shell the user uses on the remote host
#
    exec $rsh  $clienthost $rshoptions exec /bin/csh -cf "\"setenv DISPLAY $newdisplay; $authenv $xhostvar $passenvs exec $command < /dev/null >>& $XRSH_RSH_ERRORS \" < /dev/null > /dev/null " < /dev/null 

fi

---

From: Maxwell Spangler <[email-masked]>
Date: Thu, 14 May 1998 14:16:05 -0400 (EDT)

> to go to the machine 'toronto' and kill the 'xterm' process you

Ok, that's another thing I have to do: I did check to see that Fvwm2 is
running rsh on the local linux machine, and I'm assuming it's attempting
to connect to 'toronto' and do its job, but it's their just sitting there.
Now I'll telnet to toronto and see if there is any activity.

I'm assuming the "hang" I see is Fvwm waiting for my command (rsh) to go
off, and start itself correctly before Fvwm returns to regular window
processing.  It seems to run rsh, but sit there waiting for something and
the only thing I can do is move my mouse around.. Can't select windows,
can't kill anything with the mouse, etc.

> should not be used any more. 

Well, this is my home network, only connected to the outside world via a
rare PPP connection.  As such, security isn't much of a concern, but were
I to be doing this on the internet or a more populated network, yes, ssh,
would be a great idea.  Thanks for the suggestion.

I'm trying to use rsh to start an xterm on the remote system so that as
much of the resource (memory/cpu) usage is on the remote, and only the
display is on my local system.  Essentially, I do a lot of work on the SCO
system and I want to use my Linux system as an Xterminal.  I figured rsh
to start an xterm was just as good as any way..

---

From: brian moore <[email-masked]>
Date: Thu, 14 May 1998 11:39:00 -0700

> can't kill anything with the mouse, etc.

Actually, I believe the hang is that rsh doesn't supress the std file
handles properly and ends up sleeping on the socket reading nothing.
Try redirecting stdin/out/err from/to /dev/null.

I'd cut and paste it, but I switched to ssh long ago and haven't looked
back.  (Compression over a pokey modem is wonderful... it even
compresses Xprotocol pretty well.)

> would be a great idea.  Thanks for the suggestion.

I run ssh from home, partly for security, partly for ease of use.

> to start an xterm was just as good as any way.. 

Yep ('cept for rsh's security and a bad mix with X's security), though
you do have to ensure the file handles are all closed or rsh will sleep
forever.

-- 
Brian Moore                             Kill A Spammer For Jesus
Sysadmin, C/Perl Hacker, Usenet Vandal 
--
Visit the official FVWM web page at <URL:http://www.hpc.uh.edu/fvwm/>.
To unsubscribe from the list, send "unsubscribe fvwm" in the body of a
message to [email-masked].
To report problems, send mail to [email-masked].

---

From: "C. v. Stuckrad" <[email-masked]>
Date: Fri, 15 May 1998 19:25:00 +0200 (MET DST)

> rsh -l maxwell toronto "/usr/bin/X11/xterm -display maxwax:0.0"

This _normally_ works well, but (*)

...
> .fvwm2rc file, it hangs when I execute it.

I've seen rsh's hanging, waiting for 'unnecessary' filedescriptors
which were inherited from their parent process!
So if the shell closes all descriptors before starting rsh but fvwm
somehow doesnt, *then* you might be in a fix. I once wrote a little Program
called 'claoseall' (used like nice and such) which closes all except the
first three descriptors, then execs the rest of the command line.

Sometimes though it's enough to run 'rsh without input' (with option '-n')
like 'rsh -n -l user host command'

...
> X or ALT-backspace to shut X down and restart.

This is *really* strange! I only have the idea to look for fvwm
being blocked by waiting for something which never happens :-)
Did you try to kill 'fvwm itself' (or does your session end then, so you
can't do that easily).

Somebody else advised to use 'ssh' !  I strongly soc[uo]nd that notion!
(OOPS, my vocabulary is slowly leaking... was that correct? )

'ssh' is a lot more secure and simpler anyway. Use it with '-n'
too in case you 'only start an xterm'.

   Stucki

Christoph von Stuckrad       * *  | talk to  | <[email-masked]> \
Freie Universitaet Berlin    |/_* | nickname | ...!unido!fub!leibniz!stucki|
Fachbereich Mathematik, EDV  |\ * | 'stucki' | Tel:+49 30 838-75459        |
Arnimallee 2-6/14195 Berlin  * *  |  on IRC  | Fax:+49 30 838-75454       /