Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!elroy.jpl.nasa.gov!decwrl!sgi!rpw3@rigden.wpd.sgi.com
From: rpw3@rigden.wpd.sgi.com (Rob Warnock)
Newsgroups: comp.sys.sgi
Subject: Re: Problem starting X apps without csh
Message-ID: <88522@sgi.sgi.com>
Date: 2 Mar 91 02:08:40 GMT
References: <9102261506.AA03162@coho.lerc.nasa.gov> <1991Mar1.133243.25101@eagle.lerc.nasa.gov>
Sender: guest@sgi.sgi.com
Reply-To: rpw3@sgi.com (Rob Warnock)
Organization: Silicon Graphics, Inc., Mountain View, CA
Lines: 80

In article <1991Mar1.133243.25101@eagle.lerc.nasa.gov>
fsfacca@ZoSo.lerc.nasa.gov (Tony Facca) writes:
+---------------
| Apparently the csh gets the [$DISPLAY] information from .cshrc in time,
| but tcsh didn't, and of course, sh doesn't use .cshrc
| So to ensure that the variable is set, Scott [Henry, SGI] suggested setting
| it explicitly in user.ps   This worked:
| /RestartActions [
|     {
|	 ...
|        (DISPLAY) (:0) putenv
|	 ...
+---------------

(*sigh*) As the venerable sage Murphy once said, "It ain't that simple."

This will work for a single-user system that never does any networking,
but creates problems if you are in an environment where the network is
used a lot (especially "rlogin" and "rsh"). When running an X application
remotely, one usually wants it to display back on the workstation on which
one originally logged in. It would be nice to have this be automatic,
especially if people move around a lot or if several people tend to use
the same remote applications or if remote shell scripts themselves tend
to run additional applications remotely.

First, the quoted fragment only sets DISPLAY for programs which are
children of a NeWS/4Sight console session (things started by "inetd"
are not), and second, it sets it in a way which is not exportable.
In either situation, having it be set unconditionally by some high-level
process makes it hard to "do the right thing".

Suppose you want to run an "xterm" on some other system, and have it
display back on your system, e.g. "rsh there xterm -display $DISPLAY".
With the above definition, ":0", the remote "xterm" will display on the
*remote* X server, probably not what you intended. A better choice of
DISPLAY in this case would have been:

	setenv DISPLAY `hostname`:0

(or whatever the equivalent might be in PostScript). Since "xterm" exports
the value of DISPLAY it's using to its children, chains of "rsh xterm"s
would then work correctly.

But "xterm" is not the only thing one runs remotely. Suppose you run a
remote shell script:

	rsh somewhere /some/path/to/a/script

and deep in that script, it wants open an X window. Well, if the script
itself doesn't take a "-display" argument (and it might not, who knows),
the "rsh" had better have set the $DISPLAY correctly. Provided that the
remote system is an SGI Iris, this is easy. Just put the following in
your ~/.cshrc on the remote system:

	# set X windows environment
	if( ! $?DISPLAY && $?REMOTEHOST)then
		setenv  DISPLAY $REMOTEHOST':0'
	endif
	if( ! $?DISPLAY )then
		setenv  DISPLAY `hostname`:0
	endif

This depends on the fact that SGI "rshd" (remote shell daemon) sets the
environment variables REMOTEHOST and REMOTEUSER. (But if the remote host
is something else, then the remote script had *better* take a "-display"
argument! And it had better "setenv" that to all its children.)


-Rob

p.s.
I have been told that the $DISPLAY value ":0" is "more efficient" than
"hostname:0", because if you use the former, "the most efficient local
transport will be chosen" (according to "man 1 X"), which [today!] is
Unix domain sockets, not TCP. Well, that may be so [today] for a stand-alone
system, but if any significant amount of networking is being done, I'd
rather give up a few percent of X speed for hassle-free distributed
computing. And besides, any decent X library should always use "the
most efficient local transport" if the hostname part of $DISPLAY is
equivalent to the local host.