[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