[GRASS5] The status of 5.0

[rgrmill at rt66.com]

Glynn 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.

> 
> Shell scripts ought to be calling e.g. "eval `g.gisenv`" themselves 
to
> obtain the current settings from $GISRC.

True.

> [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.

Unless that has changed since pre2.  If it has then I'll probably just 
cuss a lot.

The main difficulties have been with getting the gis environment 
correctly initialized in the manager itself and with synchronizing the 
value of the MONITOR environment variable between the manager and the 
gis environment.


Roger Miller