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

[Paul Kelly]

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