[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