SUMMARY: OpenWindows 3 and Sunview Incompatibility (?)

From: Joel L. Seber ... CH210 (JLS2013@TNTECH.BITNET)
Date: Thu Feb 27 1992 - 01:48:46 CST


My compliments to the list! I received 11 replies and everyone hit it on the
head one way or another. My original question:
 
======================
 
Systems: Sparcstation 1+, 2, IPC
Memory : at least 16MB
OS : SUNOS 4.1.1
Patches: None except for "large executable" on SS2
 
I just installed OpenWindows 3 on a network node and serve it (to run
locally) to various systems. I know it's slow, etc., but I have no local disk
space for it. I set up my path and the OPENWINDOWS environment variable as
described in the installation instructions. I have run
/openwin3/bin/install_openwin on the server and the
three remote workstations. I even tried the OS patches supplied with OW3
after it initially failed.
 
The failure occurs when I try to run Sunview with OW3 path stuff in my
.cshrc. I get the gray startup screen, and 'calentool' pops up correctly.
On all other shells, tools, etc., I get the following message:
 
XView error: Cannot open connection to window server: :0 (Server Package)
 
and then nothing. I can pull up the main menu and exit Sunview.
 
I realize that something in $OPENWINHOME/bin or $OPENWINHOME/lib is making
Sunview think it should be running under OW3 ( I did install full OW3, with
Sunview support ), and I can get around this by taking out the OW3 material
from .cshrc.
 
However, another curious thing happens: even though I am already running
'selection_svc' on a station, another copy appears for every run I attempt
to make of Sunview. I suspect that this is tied to the events described
above, but I need to know if anyone else has experienced this.
 
I will summarize.
 
=======================
 
Now the summary:
 
The answer in a nutshell is: You must not have $OPENWINHOME/bin, etc., in
your path if you want to run SunView as your GUI sometimes. The simplest,
best solution is to create a shell script that adds the correct items to
your path and runs Openwindows itself; exiting the script exits changes to
your path. One problem with this is that .cshrc (if you are running the
C-shell) is executed every time you fire up a new shell, so your
$OPENWINHOME stuff does not enter your path. Several responders sent their
own scripts that address this problem. If anyone wants a copy of these, I
can mail them to you.
 
The best solution seems to be setting an environment variable, checking
it in your .cshrc, and setting your path accordingly. This is what I have
done, in a manner something like this:
 
...
set path = ( . /bin /etc/bin /usr/ucb .... )
if ( $GUI_TYPE == "openwin" ) then
      set path = ( $OPENWINHOME/bin $path )
endif
...
 
I set the GUI_TYPE environment variable with a shell script just after
login, as sometimes I work straight from the non-GUI startup screen.
 
Thanks very much to the following people:
 
eckhard@ts.go.dlr.de (Eckhard R"uggeberg)
dworkin@merlin.rootgroup.com (Dieter Muller)
ems@ccrl.nj.nec.com (Ed Strong)
macphed@dvinci.usask.ca (Ian MacPhedran)
deltam!dm!mark@uunet.uu.net (Mark Galbraith, who has never failed me!)
trdlnk!mike%uunet.uu.net@harvunxw.BITNET (Michael Sullivan)
david%mrsi.org@lbl.Bitnet (David Mostardi)
ames!elroy.jpl.nasa.gov!genisco.gtc.com!kat%harvard@harvunxw.bitnet
                               (Kathryn Fielding)
tom@sees.bangor.ac.uk (Tom Crummey)
paulo@dcc.unicamp.ansp.br (Paulo L. de Geus)
hans@smab.se (Hans C Larsson)
 
 
 
Joel L. Seber | Dry humor is wasted around here.
SUN Workstation Laboratory Manager |
Center for Manufacturing Research | -Joel L. Seber
      and Technology Utilization |
Tennessee Technological University | recursive, adj.
Cookeville, TN 38505 | See 'recursive'
                                        |
jls2013@tntech.bitnet |



This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:36 CDT