[GRASS-dev] G.region bug when setting 3d resolution??? Maybe not
Paul Kelly
paul-grass at stjohnspoint.co.uk
Thu Jan 4 09:54:02 EST 2007
On Wed, 3 Jan 2007, Michael Barton wrote:
> On 1/3/07 10:13 PM, "Paulick Consult" <stefan.paulick at urbeli.com> wrote:
>
[...]
>> And I do not understand why the data exchange over the modules is not
>> encapsulated. Would be more than helpful for grass 7 to become free of the
>> position of values inside a text stream - as we have seen... ;-)
>
> Not sure what you mean here.
I don't think, that the problem is the way the data exchange is handled,
just that gis.m should be a *little* bit more robust in its handling of
the output from g.region and other commands used in a similar way to get
information about the GRASS environment. My two recommendations would be:
1. Merge the output of stdout and stderr for any commands called like
this, by adding "|& $env(GISBASE)/etc/grocat" to the end of the command
line.
Reason: This will stop Tcl bombing out completely if anything is written
to stderr (a warning or message, for example).
2. Make the parsing of the command output more robust by actually checking
the return value of the regexp command (or whichever other Tcl command is
used to parse the output) before acting on it.
Reason: If an unexpected line occurs in the output (e.g. a warning) and it
isn't matched by the regexp, then it will be simply skipped over and no
action will be taken.
I'm willing to help with examples for these if necessary. I think
improving the robustness of gis.m like this would make debugging problems
with the GRASS set-up a lot easier.
Paul
More information about the grass-dev
mailing list