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

[Michael Barton]

I've fixed the issues that arose from the changes to g.region and committed
the updates to the cvs. Thanks again to Bernhard for getting me set up for
cvs access from home.

Michael


On 1/3/07 1:53 AM, "Paul Kelly" <paul-grass at stjohnspoint.co.uk> wrote:

> Hello Martin
> 
> On Wed, 3 Jan 2007, Martin Landa wrote:
> 
>> Hi,
>> 
>> 2007/1/2, Paul Kelly <paul-grass at stjohnspoint.co.uk>:
>> 
>>> 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?
>> 
>> not sure, there are *a lot of flags* in g.region module. Adding a new
>> one which generally have the same impact as the -g flag (i.e.
>> key=value output) -- I don't know.
>> 
>> Now `g.region -g` (still there is a warning message) is the same as
>> `g.region -pg`. I think that the -g or --g flag should have the same
>> meaning in all GRASS modules: to print parsable output. I changed the
>> -g flag behaviour mainly because I wanted to allow user to use this
>> flag in connection with other print flags, e.g. `g.region -eg`.
> 
> Yes its definitely not a bad thing to sort out the inconsistencies; you
> just need to also check how they affect other parts of GRASS. In
> particuar, gis.m seems to be quite tightly bound to the existing
> behaviour of g.region and its quirks. If you grep for g.region in the
> gui/tcltk/gis.m directory you will see quite a few places where it is
> called with different flags and then the output parsed with a regular
> expression. The return value of the regexp command isn't checked anywhere,
> so if the regular expression doesn't match the output from g.region
> exactly (e.g. because of the new features) then it will fail at some
> stage.
> 
> So it would be worthwhile I think to look at the existing uses of g.region
> and the matching regexps in gis.m and see if they can be rationalised to
> make best use of the new features of g.region.
> Worth checking throughout the whole source code actually - there are a lot
> of things that call g.region and parse its output. Like I said, definitely
> a good idea to sort out the inconsistencies but need to stay
> backward-compatible until we fix everything that depended on the old
> behaviour.
> 
> Paul
> 

__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton