[GRASS5] Need help debugging problem with thematic mapping script

Glynn Clements glynn at gclements.plus.com
Mon Nov 14 04:58:02 EST 2005


Michael Barton wrote:

> I¹ve run into a small but annoying bug that shows up when implementing the
> thematic mapping script in the GIS Manager.  I¹ve tried innumerable ways to
> fix this...trying tweaks in d.m.tcl, d.vect.thematic, and thematic.tcl--but it
> still occurs. Here is the strange behavior.
> 
> If you create a thematic map layer in the GIS Manager, and select the option
> to create a graphic legend, the GIS Manager will hang unless the monitor for
> the legend display is already running. If the monitor for the legend is NOT
> running, d.vect.thematic will start the monitor and draw the legend.
> However, all processing will then stop and the GIS Manager will hang. If you
> close this monitor, processing will continue and the GIS Manager will
> respond. If the monitor chosen for the legend IS running, processing will
> proceed normally.
> 
> As far as I can tell, this behavior is the same regardless of how the script
> is actually run in the GIS Manger (i.e., run using the TclTk open command,
> run in a terminal, run using exec, etc.).
> 
> Here is what is actually happening in the script. If you create a thematic
> map layer in the GIS Manager, and select the option to create a graphic
> legend, the d.vect.thematic script will use an if clause to check to see if
> the monitor selected for the legend is running. If the monitor chosen for
> the legend is NOT running, the script will start the monitor (d.mon start=).
> If it IS running, the script will select that monitor (d.mon select=). Then
> the script will continue to erase the monitor (d.erase), draw the legend
> using d.graph (d.graph input=), and reselect the original display monitor
> used for thematic map display (d.mon select=).

Tcl's exec command (which is being called by the default undefined
command handler; you're trying to run d.mon as a Tcl command, where it
should really be "exec d.mon ...") sets the process' stdout to a pipe.

The result of the exec command is the data which the process writes to
its stdout (the pipe), so exec can't return until it receives EOF,
i.e. when the write end of the pipe has been closed.

The driver is a child of d.mon, and so inherits the pipe as its
stdout. It never closes it, so the exec command won't get EOF and
won't terminate.

The easiest solution is to add >/dev/null or >@stdout to the exec
command.

-- 
Glynn Clements <glynn at gclements.plus.com>




More information about the grass-dev mailing list