[GRASS5] nviz problem

[Bob Covill]

Glynn,

The original reason I had changed nviz to run directly as nvwish was the 
error handling. All errors seemed to generate the same unhelpful output 
when passed through the original script. Somthing along the line of ...

.............
child killed: segmentation violation
     while executing
"exec /usr/local/grass5/etc/nviz2.2/NVWISH2.2 -f
/usr/local/grass5/etc/nviz2.2/scripts/nviz2.2_script -q -name NVIZ
 >&@stdout"
     ("eval" body line 1)
     invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f
$env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ >&@stdout"
     invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f
$env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdou..."
.................

This wasn't very helpful. It generates the same message whether a minor 
error or a more complex error is encountered. As an example try starting 
nviz with state=fakename. The old version would fatally crash with an 
error similar to above. If passed directly to nvwish (new version) a 
non-fatal error window tells you the file does not exist.

Interestingly, when I started looking into this I notice that v.digit is 
written as a modified wish (I think?).

What would be the best front-end to nviz? It needs to satisfy G_gui(), 
allow errors to handled more cleanly, and allow by-passing G_parser when 
in script mode.

--

Bob

Glynn Clements wrote:
> [I'm currently recovering from a hard drive failure, and have only
> just started catching up on the email backlog.]
> 
> Bob Covill wrote:
> 
> 
>>The script is mean't as a temporary fix so that you can run nviz with
>>options in the background (&). Try "./i -q &" and nviz should start up
>>in quick mode running in the background.
>>
>>Nviz uses both G_parser and wish style arguments. In other words nviz is
>>   a customized version of wish that accepts GRASS style commands. The
>>trick is to make sure that the GRASS commands are not stripped out by
>>the TK wish portion. The "-f" flag tells it to execute the script
>>(nviz2.2_script in our case) in the same way that wish would execute a
>>script. Remember that the current nviz executable is simply the old
>>NVWISH renamed.
>>
>>The problem seems to be related to the fact that nviz2.2_script is
>>currently executed internally with Tcl_Eval. If nviz is executed in the
>>background the whole thing hangs up. The trick is to figure out how to
>>call this correctly?
> 
> 
> When run without the -f switch, "wish" behaves like a shell, i.e. it
> reads from stdin. If wish is run via a shell running on a terminal,
> stdin will normally refer to the process' controlling terminal.
> 
> If a process which isn't a member of the foreground process group
> (i.e. one which is running in the background) attempts to read from
> the controlling terminal, it will receive SIGTTIN; the default
> behaviour of that signal is to suspend the process (similar to SIGSTOP
> and SIGTSTP).
> 
> NVIZ shouldn't behave like a shell so, if it is implemented as a
> typical "enhanced wish", it must always be run with the "-f" switch.
> 
> IMHO, eliminating the nviz script and renaming the NVWISH2.2
> executable to "nviz" was a mistake. I presume that this was done in
> response to the G_gui() issues, but I think that it's the wrong
> approach.
> 
> It would probably have been better to force G_gui() to call "nviz"
> rather than using the name of the current executable, either by
> manipulating argv[] or by adding a function to parser.c to allow a
> module to specify its name.
>