weening@Gang-of-Four.Stanford.EDU (Joe Weening) (11/30/88)
I have been using a command of the form
"rsh remotehost -n 'exec /usr/bin/X11/xterm >& /dev/null' &"
bound to a window manager menu (twm, in case it matters) to start up
an xterm on a remote host. Under X11R2, both the local rsh process
and the remote rshd would go away after xterm was started. But under
X11R3, this doesn't seem to work; the xterm runs fine, but rsh and
rshd stay around. Does anyone know what changed?
--
Joe Weening Computer Science Dept.
weening@Gang-of-Four.Stanford.EDU Stanford Universityjonnyg@umd5.umd.edu (Jon Greenblatt) (12/01/88)
In article <5345@polya.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU (Joe Weening) writes: >I have been using a command of the form > > "rsh remotehost -n 'exec /usr/bin/X11/xterm >& /dev/null' &" This is a very inefficient way of doing things. The X Window buffers ar far more numerous than the equivalent rsh buffers as far as I know. Try the following: "xterm -e rlogin remotehost" This will also solve your problem with hanging processes. Resize will still work if your display is set correctly. JonnyG.
schwartz@shire.cs.psu.edu (Scott Schwartz) (12/01/88)
In article <4292@umd5.umd.edu>, jonnyg@umd5 (Jon Greenblatt) writes: >In article <5345@polya.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU writes: >> "rsh remotehost -n 'exec /usr/bin/X11/xterm >& /dev/null' &" How about this: rsh remotehost -n "xterm -display myhost:0 >& /dev/null &" Running xterm in the background lets rlogind (and thus rsh) exit immediately. > This is a very inefficient way of doing things. The X Window buffers >ar far more numerous than the equivalent rsh buffers as far as I know. What does that mean, and how does it relate to efficiency? Is it more expensive to let xterm send (possible batched) bitblt commands than to have every character wend its way through rlogind? Also, doesn't remote xterm mean fewer processes on the local machine than what you suggest? >Try the following: > "xterm -e rlogin remotehost" > This will also solve your problem with hanging processes. Resize >will still work if your display is set correctly. I could run Suntools if I wanted to do it that way! :-) :-) Anyway, that technique doesn't preserve the notion of network transparency. For example, you have to set DISPLAY by hand to get things to work right. -- Scott
jonnyg@umd5.umd.edu (Jon Greenblatt) (12/01/88)
In article <4292@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes: >In article <5345@polya.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU (Joe Weening) writes: >>I have been using a command of the form >> >> "rsh remotehost -n 'exec /usr/bin/X11/xterm >& /dev/null' &" > > This is a very inefficient way of doing things. The X Window buffers >ar far more numerous than the equivalent rsh buffers as far as I know. >Try the following: > > "xterm -e rlogin remotehost" Well I put my money where my mouth used to be and found that I am mostly wrong. If the window is being used as a standard terminal with character input and output, xterm is more efficient than rlogin. If however you are doing a lot of cut and past or the window is being affected by numerous external events then rlogin is more efficient. If speed is at all important to you xterm is 5-10 times faster. I now remove the foot from my mouth. I established this using a netwatch program. I still prefer rlogin becuse I have always had problems with lingering processes and what not using xterm remotely. Maybe I'm just old fashioned. JonnyG.
gandalf@csli.STANFORD.EDU (Juergen Wagner) (12/01/88)
In article <4292@umd5.umd.edu> jonnyg@umd5.umd.edu (Jon Greenblatt) writes: >In article <5345@polya.Stanford.EDU> weening@Gang-of-Four.Stanford.EDU >(Joe Weening) writes: >> "rsh remotehost -n 'exec /usr/bin/X11/xterm >& /dev/null' &" > > This is a very inefficient way of doing things. The X Window buffers >ar far more numerous than the equivalent rsh buffers as far as I know. >Try the following: > > "xterm -e rlogin remotehost" >... That's not the point. The two rsh processes will go away as soon as the remote job is done (i.e. as soon as the xterm is forked). There won't be any rsh's sitting around and idling. The xterm will just open a connection to the X server, independently of the rsh line. Now here a suggestion: I have no idea what is broken in rsh/xterm/..., and what changed form R2 to R3. How about rsh HOST -n "xterm ${DISPLAY} >& /dev/null &" and dropping the exec. I think the DISPLAY is necessary. It works for me. Good luck, -- Juergen Wagner gandalf@csli.stanford.edu wagner@arisia.xerox.com
mtr@mace.cc.purdue.edu (Miek Rowan) (12/01/88)
In article <4293@umd5.umd.edu>, jonnyg@umd5.umd.edu (Jon Greenblatt) writes: > by numerous external events then rlogin is more efficient. If speed is > at all important to you xterm is 5-10 times faster. I now remove the foot > from my mouth. I established this using a netwatch program. I still > prefer rlogin becuse I have always had problems with lingering processes and > what not using xterm remotely. Maybe I'm just old fashioned. But with the rsh's you can totally dedicate your slow workstation to running the X server (and unix) -- I find the degradation with some 20 windows open too much (when running all the xterms (and whatnot) on the workstation) Offload those things to other peoples machines! Be Inconsiderate! ;-) Besides, when I get mad at Sun and thier product I can still use my workstation without even having a login shell there. It is great :-) ;-) mtr
jim@EXPO.LCS.MIT.EDU (Jim Fulton) (12/01/88)
> rsh HOST -n "xterm ${DISPLAY} >& /dev/null &"
minor nit:
rsh HOST -n "xterm -display ${DISPLAY} >& /dev/null &"tom@ICASE.EDU (Tom Crockett) (12/02/88)
> ... both the local rsh process and the remote rshd would go away > after xterm was started. Just to complicate the discussion, there might be a reason for wanting to keep the "rsh" around. It seems that the source code for xterm is littered with fprintf's to stderr. If you redirect stderr and stdout for the remote xterm to /dev/null and dispose of the rsh process, then you wouldn't get any potential error messages. If you kept rsh around and don't redirect, then error messages would come back to your server machine (probably to /dev/console, if you started rsh from a window manager menu). But then again, how often does "xterm" generate errors? Not very, from my experience. Tom Crockett -------------------------------------------------------------------------------- Institute for Computer Applications in Science and Engineering M.S. 132C, NASA Langley Research Center Hampton, VA 23665 e-mail: tom@icase.edu phone: (804) 865-4097 --------------------------------------------------------------------------------
chris@mimsy.UUCP (Chris Torek) (12/08/88)
I use the following script (called `xrsh') to start commands on remote
machines. It leaves no extra processes, and exports DISPLAY to the
remote machine (which rsh does not). It does assume you use the C
shell, although changing this is trivial: make the last line
rsh $host -n "DISPLAY=$DISPLAY exec $@ </dev/null >/dev/null 2>&1"
#! /bin/sh
#
# start an X11 process on another host
#
# simply exports $DISPLAY, and runs the given command
case $# in
0|1) echo "usage: $0 host cmd [args]" 1>&2; exit 1;;
esac
: ${DISPLAY-"no DISPLAY environment variable"}
host="$1"
shift
rsh $host -n "setenv DISPLAY $DISPLAY; exec $@ </dev/null >&/dev/null"
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chrismayer@hplabsz.HPL.HP.COM (Niels Mayer) (12/09/88)
In article <14904@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: >I use the following script (called `xrsh') to start commands on remote >machines. It leaves no extra processes, and exports DISPLAY to the >remote machine (which rsh does not). > >rsh $host -n "setenv DISPLAY $DISPLAY; exec $@ </dev/null >&/dev/null" FYI: There's one small problem with schemes that pass along $DISPLAY. On my workstation, I have my $DISPLAYs set to unix:0.0 and unix:0.1 so that local clients communicate with the server using unix domain sockets (giving a substantial speed improvement). Passing along unix:0.* to the remote host is of course meaningless, since the remote host expects `hostname`:0.*. In my scripts, I kludged around this problem by using a conditional that tests for the two possible cases that arise in my configuration. I didn't have the time or patience to coax sh into automatically replacing the substring "unix:" with "`hostname`:". That would of course be the "right" solution. -- Niels.