sahayman@iuvax.cs.indiana.edu (Steve Hayman) (04/15/89)
Many X users that I've seen seem to have something like this in, for instance,
a .login file on a big Vax, to figure out what to set their DISPLAY
environment variable to whenever they rlogin from a workstation:
if ( $TERM =~ xterm* ) then
echo -n "What workstation are you using ? "
# oops, I got this line wrong the first time I posted this...
set host=$<
setenv DISPLAY ${host}:0
endif
or if they really want to get fancy and try to figure it out
automatically,
if ( $TERM =~ $xterm* ) then
# "who am i" shows something like
# iuvax!sahayman ttyrd Apr 14 12:25 (cssun1)
# so cut out the remote host part
set rhost=`who am i | sed -e 's/.*(//' -e 's/.)*$//'`
setenv DISPLAY ${host}:0
endif
Unforunately the latter technique is a kludge at best, and fails
if you do a chain of rlogins, since the "who am i" has no way of telling
you the original machine that you started on.
[Please stop me right here if there's some better way to do this that
I don't know about. Thanks]
A suggestion. xterm knows what the right DISPLAY is, since xterm is
actively using that information. How about we extend the xterm protocol
a bit so that there is some escape sequence you can send it that will
case xterm to echo back what its idea of the DISPLAY variable is.
That way, your .login file could simply echo a few bytes and
read back a string and set the DISPLAY according to that string
The same idea as eval `resize`.
This would work across chains of rlogins, since the escape sequence
would be interpreted by the original xterm and not by anything on
any of the intervening hosts.
As an experiment, I made this particular modification to our own xterm here,
having more or less chosen a suitable escape sequence at random. In fact
I made it a bit more general, <esc> ] 999 ; STRING <bel> makes
xterm echo back the value of its environment variable STRING.
(If one was gung ho, one could also make it echo back other xterm private
variables such as the current window name, etc etc, but DISPLAY
is about the only thing I can think of a use for at the moment.)
Perhaps something like this would be a worthwhile addition to the
standard xterm. Anybody else got a better way to set your DISPLAY?
..Steve
--
Steve Hayman Workstation Manager Computer Science Department Indiana U.
sahayman@iuvax.cs.indiana.edu (812) 855-6984janssen@titan.sw.mcc.com (Bill Janssen) (04/17/89)
If xterm is true vt102 emulation, it will have an answer-back escape sequence, which is used by some DEC systems to interrogate the terminal in order to determine special information. In fact, if memory isn't playing me false, the vt100 had two interrogation sequences, one for asking for the terminal's type, the other for getting the user-supplied answer-back message, no? Bill
bob@tinman.cis.ohio-state.edu (Bob Sutterfield) (04/18/89)
These problems (trying to figure out DISPLAY over rlogin) are much simpler when the xterm itself is running on the remote system. It can get its DISPLAY at startup time, as when using an rXcmd script like: #!/bin/sh # rXcmd (suggested by John Robinson, jr@bbn.com) # (generalized for sh,ksh by Keith Boyer, keith@cis.ohio-state.edu) case $# in [01]) echo "Usage: $0 host x-cmd [args...]";; *) case $SHELL in *csh*) host="$1"; shift xhost "$host" rsh "$host" -n \ "(setenv TERM xterm; setenv DISPLAY `hostname`:0; \ $* </dev/null >& /dev/null &)" & ;; *sh) host="$1"; shift xhost "$host" rsh "$host" -n \ "(export TERM=xterm; export DISPLAY=`hostname`:0; \ $* < /dev/null > /dev/null 2>&1 &)" & ;; esac ;; esac The bit about setting DISPLAY to `hostname`:0 is a bit of a hack, but at least it works for both X10 and X11. DISPLAY locally will be something like "unix:0.0" which of course isn't too useful over a TCP-domain socket, so another approach is needed. Suggestions welcome... (I have a similar rPScmd for use in NeWS-land.) Some have suggested that in a resource-poor environment, running the xterm client on the remote system causes more of a load than would an rlogind or telnetd, because of the CPU and network overhead of managing life as a real X client, with exposure and mouse-entry events and such like that the VAX-11/730 or Cray (or whatever) shouldn't have to worry about. You just have to decide whether the remote system or your own workstation has more memory and cycles to spend on that sort of stuff, and work out the tradeoff in each particular case. Does anyone know the general answer: how do the network, memory, and CPU loads on the host compare between xterm, rlogind, and telnetd in a typical 4.3-like system?
rlk@THINK.COM (Robert L. Krawitz) (04/18/89)
This gets the DISPLAY variable correct: setenv XDISPLAY `hostname`:`echo $DISPLAY | sed 's/.*://'` (I use the XDISPLAY variable to pass across an rlogin via some TERM variable munging, but I want my local DISPLAY variable to be unix:0.0). ames >>>>>>>>> | Robert Krawitz <rlk@think.com> 245 First St. bloom-beacon > |think!rlk (postmaster) Cambridge, MA 02142 harvard >>>>>> . Thinking Machines Corp. (617)876-1111
jg@crltrx.crl.dec.com (Jim Gettys) (04/18/89)
> >Does anyone know the general answer: how do the network, memory, and >CPU loads on the host compare between xterm, rlogind, and telnetd in a >typical 4.3-like system? Back in V10 days, I did some measurements which showed xterm using around 1/2 the cpu time as a rlogin. But at that point, xterm had been carefully performance tuned (it has since become much fancier and more bloated), so the measurements are hardly valid these days, without further information. But blindly presuming that X applications are necessarily "more expensive" than terminal applications doing the identical thing is a very poor idea in general; sweeping generalizations are very perilous. It is certainly the case that people tend to demand more out of window based environments (for example, my display (DECstation 3100) can run more than 50,000 characters/second, wheras 9600 baud sets a limit of 1000 characters/second as a rate a program could be generating text for a user). So I certainly can demand more of a machine than I could in the past, when there was a soda straw between me and the machine I was using. - Jim
scott@grlab.UUCP (Scott Blachowicz) (04/20/89)
One thing I've done is to pass it along on the $TERM variable...I would setup
a script (xrlogin) (by the way, we're on an HP system):
#! /bin/sh
hostname=`hostname`
DISPLAY=`echo ${DISPLAY:-unix:0.0} | sed "s/^unix:/$hostname:/"`
TERM=hpX$DISPLAY
export DISPLAY TERM
exec rlogin $*
then, my .profile(or .login or whatever) would check for the current
value of the $TERM variable:
case "$TERM" in
hpX*)
DISPLAY=`expr substr "$TERM" 4 99` export DISPLAY
PATH=/usr/bin/X11:$PATH
eval `tset -s hpX`
eval `/usr/bin/X11/resize`
;;
*) eval `tset -s "local:${L0:-hp2397}" ${L0:-hp2393}`;;
esac
This assumes that the remote system's system-wide login procedure didn't
blast your $TERM (in /etc/csh.login,/etc/profile or whatever).
Boy is that a kludge, seems there should be a way to have rlogin pass
through environment variables for you.
---
Scott Blachowicz
USPS: Graphicus UUCP: ...!hpubvwa!grlab!scott
150 Lake Str S, #206 VoicePh: 206/828-4691
Kirkland, WA 98033 FAX: 206/828-4236marco@buengc.BU.EDU (Marco Zelada) (04/24/89)
In article <19688@iuvax.cs.indiana.edu> sahayman@iuvax.cs.indiana.edu (Steve Hayman) writes: > >Many X users that I've seen seem to have something like this in, for instance, >a .login file on a big Vax, to figure out what to set their DISPLAY >environment variable to whenever they rlogin from a workstation: How about the following: setenv DISPLAY `hostname`:0 hostname will return the name of the machine you are login onto. -- ________________________________________________________________________________ Name: Marco Zelada Phone: 617 353 9882, Fax: 353 6322 VLSI CAD Engineer E-mail: marco@buengc.bu.edu Dept: Electrical & Computer Eng. Mail: 44 Cummington St. Room 236 Org: Boston University Boston MA, 02215 ________________________________________________________________________________
envbvs@epb2.lbl.gov (Brian V. Smith) (04/25/89)
> >Many X users that I've seen seem to have something like this in, for instance, > >a .login file on a big Vax, to figure out what to set their DISPLAY > > > setenv DISPLAY `hostname`:0 > > hostname will return the name of the machine you are login onto. > The problem is that if you are remotely logged in to some host that is NOT the display server (which is one of the strong points of X), then the hostname command will not give you the hostname of the X server. _____________________________________ Brian V. Smith (bvsmith@lbl.gov) Lawrence Berkeley Laboratory We don't need no stinking signatures!
guido@cwi.nl (Guido van Rossum) (04/25/89)
Locally, we use this script (called xremote) which can start an arbitrary program remotely. We also have a specialization (called xrlogin) which is equivalent to "xremote <hostname> xterm -ls". All this only works for sh or ksh (no csh lovers here). Improvements over other scripts published before: knows not to touch $DISPLAY if it doesn't start with ":" or "unix:"; sets $PATH to find most X utilities (you may have to change this according to local circumstances); and it has a -d option to display error messages in case something is wrong and you can't figure out what because all I/O is lost normally (usually a bad .rhosts file, or a bad path). (The script closes all file descriptors because we encountered some problems in rshd.) #!/bin/sh # # xremote [-d] hostname xclientname [argument] ... # # Run an X client in the background in a remote machine. # The following tricks are necessary: # - set or patch the DISPLAY variable # - set the remote PATH variable case $1 in -d) set -x; shift; redirect="";; *) redirect="</dev/null >/dev/null 2>&1 3>&- 4>&- 5>&- 6>&- 7>&- 8>&- 9>&- &";; esac case $# in 0|1) echo "usage: xremote [-d] hostname xclientname [argument] ..." 1>&2; exit 2;; esac host=$1 shift local=`hostname` case $DISPLAY in :*) display=$local$DISPLAY;; unix:*) display=`echo "$DISPLAY" | sed "s/unix/$local/"`;; *) display=$DISPLAY;; esac rsh "$host" \ "DISPLAY=$display" \ "PATH=:/bin:/usr/bin:/usr/ucb:/usr/local:/usr/local/X/bin" \ "$@ $redirect" $redirect -- Guido van Rossum, Centre for Mathematics and Computer Science (CWI), Amsterdam guido@cwi.nl or mcvax!guido or guido%cwi.nl@uunet.uu.net "Repo man has all night, every night."
alberto@tove.umd.edu (Jose Alberto Fernandez R) (04/27/89)
For csh and tcsh users this group of aliases perform the connection
with the remote system and starts the X11 application.
---- CUT HERE ------
#X environment, remote connection.
#This alias must recide in your .cshrc or .tcshrc
#You need to have this alias in both sides of the connection
#and be able to RLOGIN without password verification.
#This alias (called ">" ) starts a login XTERM in the remote machine,
#is call as:
# > hostname [-l user]
#
alias ">" '>> "\!*" xterm -n \!:1 -ls'
#This alias (">>") is used to start any remote xapplication that you want,
#is call as:
# >> "host [-l user]" prog args....
#
# The first argument is the parameters for RSH
alias ">>" '(set m=\!:1;rsh $m -n "<<" $DISPLAY \!:2-* )</dev/null >/dev/null'
#This alias ("<<") is the receptor in the remote system.
#is call in the remote connection as:
# << display_server prog args...
alias "<<" '(setenv DISPLAY \!:1 ; \!:2-* ) </dev/null >/dev/null&'
------- CUT HERE ---------
All the process are running in the background and are connected
directly to the server.
I used this alias in my .xinitrc to start XMH in my main acount.
If you want to used this aliases in menus of your window manager, be
sure that the subprocess is using CSH or TCHSH and not SH. One way to
deal with that is by specifying in TWM or UWM the command as:
!"exec $SHELL -c 'command ...' &"
-- Jose Alberto.
--
:/ \ Jose Alberto Fernandez R | INTERNET: alberto@tove.umd.edu
:| o o | Dept. of Computer Sc. |
:| ^ | Univesity of Marylad |
:\ \_/ / College Park, MD 20742 |