[GRASS5] The status of 5.0

[Glynn Clements]

rgrmill at rt66.com wrote:

> > One of the main obstacles to switching location/mapset on the fly is
> > the number of scripts[1] which reference $GISDBASE, $LOCATION_NAME,
> > $MAPSET and/or $LOCATION directly.
> > 
> > Currently, these are set in Init.sh using "eval `g.gisenv`". There
> > isn't any way to subsequently change them using an external command;
> > using "eval" is inconvenient, and shell aliases/functions are messy
> > (non-portable, aren't inherited by scripts).
> 
> That is solved.  It was difficult, but perhaps not for the reasons you 
> are envisioning.
> 
> g.gisenv calls gisinit() to initialize those values.  In fact, those 
> values are initialized again by every modules I know of (5.0pre2) by 
> calling gisinit().  All accesses to the gis environment variables, 
> including initialization in gisinit() are carried out through the 
> functions in env.c
> 
> The manager intersepts calls to the functions that read and write the 
> gis environment variables.  A more complete implementation would 
> probably replace all of the functions in env.c and it would be quite a 
> bit more efficient.  This is one case where the manager has a lot to 
> offer.

But I don't see how this helps scripts.

For C programs, switching mapsets/locations should just be a matter of
modifying the appropriate variable in $GISRC.

> > [1] AFAICT, I've fixed all of the C programs which accessed these
> > variables via getenv().
> 
> I find this a little confusing, as getenv() is used to get the values 
> from the shell environment.  MAPSET, LOCATION_NAME and so on are in the 
> gis environment, not in the shell environment.  getenv() shouldn't 
> work.

Init.sh contains the line:

	eval `g.gisenv`

This causes the contents of $GISRC to be reflected into the
environment; i.e., for each GRASS variable, an environment variable is
created with the same name and value.

This is currently necessary because most scripts just reference
$LOCATION, $MAPSET etc, and expect those variables to be set. The
scripts ought to be calling g.gisenv themselves to get the values;
this would ensure that any changes to $GISRC which occurred during the
session were visible to the scripts.

A few C programs also used getenv() when they should have used
G_getenv(), but (AFAICT) I've fixed those now.

-- 
Glynn Clements <glynn.clements at virgin.net>