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
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 )
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:
firstname.lastname@example.org (Eckhard R"uggeberg)
email@example.com (Dieter Muller)
firstname.lastname@example.org (Ed Strong)
email@example.com (Ian MacPhedran)
firstname.lastname@example.org (Mark Galbraith, who has never failed me!)
trdlnk!mike%uunet.uu.net@harvunxw.BITNET (Michael Sullivan)
david%mrsi.org@lbl.Bitnet (David Mostardi)
email@example.com (Tom Crummey)
firstname.lastname@example.org (Paulo L. de Geus)
email@example.com (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'
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:06:36 CDT