fsfacca@COHO.LERC.NASA.GOV (Tony Facca) (02/26/91)
Here is a wierd one..
When I run with "csh" as my default shell, I can start X applications
during startup, but when I use "sh" or "tcsh", I can't.
Background:
OS 3.3.1, various platforms
In /usr/NeWS/lib/user.ps I have the following lines:
.
.
/basicRestartActions [
{ establishEnvironment }
{ RunConsole }
{ startXsgi }
] def
.
.
/RestartActions [
{
(-n C_Shell -r1000 -s40x80 -t"$USER on `hostname`") forkwsh
(/usr/bin/X11/xclock -hd blue -bg grey -update 1 \
-geometry 145x145 +1095+835 &) forkunix
(/usr/bin/X11/xcalendar -geometry 275x185-50-600 &) forkunix
.
.
Under sh, csh and tcsh the forkwsh works, but under sh, and tcsh, forking
the X apps does not work.
Looking into what may be causing this, I tracked down startXsgi which comes
from /usr/NeWS/lib/NeWS/init.ps and is simply a call to "xtart -c". This
is supposed to, eventually, start up Xsgi. A "ps -ed" shows that indeed
Xsgi got started, regardless of what shell I use, one for each shell forked
during startup.
So, what can be going on? Is there some dependence on csh in order to start
X applications from user.ps?
Any ideas would be appreciated.
-----------------------------------------------------------------------------
Tony Facca | fsfacca@avelon.lerc.nasa.gov | phone: 216-433-8318
-----------------------------------------------------------------------------
You are at Witt's end. Passages lead off in *all* directions.scotth@corp.sgi.com (Scott Henry) (02/27/91)
tf> Here is a wierd one..
tf> When I run with "csh" as my default shell, I can start X applications
tf> during startup, but when I use "sh" or "tcsh", I can't.
tf> Background:
tf>
tf> OS 3.3.1, various platforms
tf>
tf> In /usr/NeWS/lib/user.ps I have the following lines:
tf> .
tf> .
tf> /basicRestartActions [
tf> { establishEnvironment }
tf> { RunConsole }
tf> { startXsgi }
tf> ] def
tf> .
tf> .
tf> /RestartActions [
tf> {
tf> (-n C_Shell -r1000 -s40x80 -t"$USER on `hostname`") forkwsh
tf> (/usr/bin/X11/xclock -hd blue -bg grey -update 1 \
tf> -geometry 145x145 +1095+835 &) forkunix
tf> (/usr/bin/X11/xcalendar -geometry 275x185-50-600 &) forkunix
tf> .
tf> .
tf> Under sh, csh and tcsh the forkwsh works, but under sh, and tcsh,
tf> forking the X apps does not work.
I don't know if this is the actual problem, but `() forkunix` already puts
the command in the background. The '&' in the command string may be
confusing the shell. I am using tcsh as my default shell under 3.3.2 and I
have no problems launching X apps.
--
Scott Henry <scotth@sgi.com> / Traveller on Dragon Wings
Information Services, / Help! My disclaimer is missing!
Silicon Graphics, Inc / Politicians no baka!fsfacca@ZoSo.lerc.nasa.gov (Tony Facca) (03/01/91)
> >When I run with "csh" as my default shell, I can start X applications >during startup, but when I use "sh" or "tcsh", I can't. > Just to close the loop, Scott Henry of SGI came up with the proper diagnosis of the problem. In summary: Since the shells might start up differently, depending upon how tcsh is configured, you cannot be sure that the X DISPLAY environment variable is set. Apparently the csh gets the 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 suggested setting it explicitly in user.ps This worked: /RestartActions [ { RunConsole . . (DISPLAY) (:0) putenv . . (/usr/bin/X11/xclock -hd blue -bg grey -update 1 \ -geometry 145x145+1095+835 &) forkunix (/usr/bin/X11/xcalendar -geometry 275x185-50-550 &) forkunix . . } ] store Thanks to everyone who responded. I've been sleeping much better lately.. -- ----------------------------------------------------------------------------- Tony Facca | fsfacca@avelon.lerc.nasa.gov | phone: 216-433-8318 ----------------------------------------------------------------------------- You are at Witt's end. Passages lead off in *all* directions.
rpw3@rigden.wpd.sgi.com (Rob Warnock) (03/02/91)
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.