Troubleshooting Your WebOOGL Installation

Are the WebOOGL scripts executable?

Make sure that the WebOOGL scripts are executable files, located in directories in your command path. You can check this with the csh command

  which weboogl.perl to-weboogl.perl gvgeturl.perl woogl2oogl vrml2oogl geomview gvx

Use the chmod command to make them executable if necessary.

Where is Mosaic installed on your system?

At some sites Mosaic is installed as the xmosaic command. This problem can be fixed by editing the configuration line near the top of weboogl.perl which reads:

   $mosaic_cmd = 'Mosaic';

Where is Perl installed on your system?

If your system manager hasn't installed perl on your system, grab a copy from the Perl Archives. Note that the WebOOGL scripts specifically assume that Perl is located in /usr/local/bin/perl. You can check where it really is with the csh command

   which perl

If it has been installed in another location, you should edit the very first line of all scripts appropriately. (For example, Irix 5 comes with Perl pre-installed, but its location is /usr/sbin/perl.)

Are you using the right version of Perl?

Note that you need version 4.036, there is a bug in perl5 which causes problems with the libwww-perl code! You can check the version by typing

   perl -v

Is the 2D browser responding to remote control?

Make sure that you are running at least version 2.2 of X Mosaic or version 1.1S of Netscape for reliable remote control. (Note: we have received one report of a copy of X Mosaic 2.4 that did not respond to remote control commands. If you have also experienced this problem on your system and tracked down the cause, please let us know.)

Do you have outdated binaries in your path ?

If you had previously installed WebOOGL 1.0, make sure the new binaries have overwritten the old ones.

Are you trapped behind a firewall?

The new WebOOGL should be capable of using proxy servers. If you are trying to connect from behind a firewall, make sure you've set up your 2D browser to use a proxy server. (This should theoretically work but has not been tested yet.)

Is it normal for the software to crash?

It's a known bug that nonlegitimate VRML files can wreak havoc. Unfortunately there are a lot of files out on the Web ending in ".wrl" that contain non-VRML constructs. The WebOOGL package relies on the QvLib parser, which is not incredibly robust and has a distressing tendency to crash on bad input. We might be able to provide more graceful failure mechanisms in the future.

Are you unable to load local files?

Sometime local files (those served through the "file" protocol instead of the "http" protocol) have the MIME content-type headers stripped. While the software attempts to recognize OOGL and VRML files anyway, if you're having troubles try putting the files in a place that's recognizeable to your Web server and using the http protocol instead. Of course, make sure your server has is configured to properly serve .wrl and/or .oogl files by adding these lines to the mime.types file:

   x-world/x-vrml	wrl
   object/x-oogl	oogl off list tlist grp quad mesh inst bez vect

Do you have a question not answered here?

Send mail to software@geom.umn.edu for further help.

Up: The WebOOGL Home Page

The Geometry Center Home Page

Comments to: webmaster@geom.umn.edu
Created: Apr 24 1996 --- Last modified: Apr 24 1996