[GRASS-dev] another not quiet GRASS command

[Glynn Clements]

Michael Barton wrote:

> >> In the above case of georect.tcl, we may ask 1) if switching between
> >> mapsets in the script is really the best solution; 2) if that warning
> >> should be a warning.
> > 
> > 3) If g.mapset is the right way to switch mapsets, or whether gis.m
> > should generate a temporary GISRC and "set env(GISRC) $tmp_gisrc".
> > 
> > If you're going to modify the existing $GISRC with g.mapset, the user
> > had better not be running GRASS commands on the terminal in the
> > meantime.
> 
> Because of the way GRASS works, it is necessary to switch between mapsets.
> i.e., a display command will only work with the current environment and an
> accessible mapset. Any operation that changes something (e.g., i.group) will
> only work in the current mapset.
> 
> However, with more experimentation, it looks like g.mapset won't work as a
> way to do this. I've had to revert to using g.gisenv
> set=LOCATION_NAME=[xy_location].

I'm not questioning whether it's necessary to switch mapsets. I'm
questioning whether modifying the existing $GISRC is the right
approach, or whether gis.m should create a new $GISRC solely for use
by the georectifier.

Personally, I'd suggest the latter.

In general, global state (e.g. $GISRC, WIND) is undesirable. For
command-line use, it's a necessary compromise, as having to manually
specify database/location/mapset (and others, e.g. monitor and
database) for each command would be a major nuisance.

A GUI doesn't have this problem; it can maintain its own state. 
Moreover, it can maintain as many different states as it wishes, and
use the appropriate one for each individual command.

See also: past discussions of $WIND_OVERRIDE and $GRASS_REGION vs the
WIND file.

-- 
Glynn Clements <glynn at gclements.plus.com>