[GRASS-user] Re: grassuser Digest, Vol 9, Issue 1

Paul Kelly paul-grass at stjohnspoint.co.uk
Tue Jan 2 14:27:17 EST 2007


On Tue, 2 Jan 2007, Paul Kelly wrote:

> Hello Martin,
> Under normal circumstances, the fix whereby -g still works but outputs a 
> warning would work fine - EXCEPT (because of a bug/feature/limitation in 
> Tcl), when GRASS commands are run from Tcl scripts stderr and stdout have to 
> be merged. So the warning (which goes to stderr) interferes with the 
> parseable output (which goes to stdout) meaning that unfortunately outputing

Actually, to make things even more complicated, that's *not* what's 
happening here. gis.m (actually mapcanvas.tcl) is running g.region -g 
*without* merging stdout and stderr, and it was the fact that anything at 
all (in this case the warning) was being written to stderr that was making 
Tcl bomb out completely. I think in this situation it may be preferable to 
work around the problem in mapcanvas.tcl:
if I change line 1056 of gui/tcltk/gis.m/mapcanvas.tcl to the following:
         if {![catch {open [concat "|g.region" "-ug" $args "|& $env(GISBASE)/etc/grocat"] r} input]} {
i.e. adding "|& $env(GISBASE)/etc/grocat" at the end of the command line,
then stdout and stderr will be merged and Tcl won't bomb out. The only 
problem then is that the call to "regexp" on the next line doesn't check 
the return value. (The warning message obviously isn't parseable, so it 
should just skip over it.) If the return value of regexp was checked 
there, and the key/value not assigned using "set" if regexp returned 
false, the gis.m startup would probably be a little bit more robust.

But the other issue is of course - should we be changing the meaning of 
the g.region -g flag at all? Why not keep it as it is and add the new 
functionality (key=value output in combination with any other flag) to a 
totally new flag, to reduce confusion and enhance backwards compatibility?

Paul




More information about the grass-user mailing list