But what if (as in my case) the command DX invokes isn't necessarily a persistent PID, but a "kick the browser" script (e.g. so you can direct an already-running browser instance)? Then the process ID test fails the second time around. Also related to this, I notice that dxui isn't wait()ing on its child, which is what's causing DX to think a browser it invoked is still hanging around:|-+- 840792 /home/rhh/software/dx/dx/bin_sgi/startupui | \-+- 840822 /home/rhh/software/dx/dx/bin_sgi/dxui -kiosk -proc | |-+- 840779 /bin/csh -f /home/rhh/software/dx/dx/bin/dxworke | | \--- 840851 /home/rhh/software/dx/dx/bin_sgi/dxexec -r -p1 --> | \--- 840925 <defunct>
If I wait on the child, then wouldn't the user have to exit the browser to return, thus locking up the dxui while you're using help? This is what I was trying to get away from by using fork.
However, backing up a step, is the DX_WEB_BROWSER functionality intended to be netscape-specific on UNIX? I don't know whether the -remote -raise openURL(<url>) command-line options are supported by all UNIX web browsers.
I guess you've dealt with this more than I. The code is pretty small for the changes that need to be made so let's hash this out.
If I strip out the code that was doing all the pid checking, etc. then just go with the solution of system( "%s \"$url\" &", browser ) and offer a script such as your url_handler, that should suffice. However, I found that with the system() call, if somebody sets this to call netscape, the dxui locks up until the process is finished. That is why I was using the fork and basically leaving defunct process lying around until the dxui quit. Does anybody have suggestions on how to handle this any other way?
David -- ............................................................................. David L. Thompson The University of Montana mailto:[EMAIL PROTECTED] Computer Science Department http://www.cs.umt.edu/u/dthompsn Missoula, MT 59812 Work Phone : (406)257-8530
