[GRASS-dev] [bug #4368] (grass) g.parser: pass through --o
Glynn Clements
glynn at gclements.plus.com
Wed May 10 19:07:40 EDT 2006
Radim Blazek wrote:
> > Actually, the "fixes" have also been rather ad-hoc. It might be better
> > to do away with WIND and store the name of a saved region in $GISRC
> > instead, remove MONITOR_OVERRIDE and WIND_OVERRIDE, and just create an
> > alternate $GISRC file whenever you want to change any of those
> > parameters.
>
> Note that it is also possible to set region with GRASS_REGION
> environment variable.
I wasn't aware of that feature. That would be simpler for running
commands with a specific region from gis.m.
However, I don't think that the way it is currently implementated is a
good idea, as it overrides all saved regions as well as the current
region. I would suggest moving it to G_get_window(), so that programs
which use G__get_window() to read a specific named region aren't
affected.
I've recently fixed a small number of modules which gratuitously used
G__get_window(..., "WIND") to get the current region.
[Most of these did so in order to handle the case where the current
region was undefined, and use the default region instead. If that's
considered a good idea, it should be done in G_get_window() so that it
works for every module, not by a handful of specific modules.]
Modifying G_get_window() should now suffice for everything which
actually wants "the current region", except for g.region (which has a
legitimate need to specifically handle the case where the current
region is invalid). Everything else that still uses G__get_window()
does so because it wants a named region, or the default region, or the
current region for some other mapset.
For future development, I'm wondering if it would be a good idea to
replace the WIND file with a GRASS variable (e.g. REGION) using the
same syntax as GRASS_REGION.
--
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev
mailing list