[GRASS5] The status of 5.0

GRASS GRASS developer
1

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

2

rgrmill@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@virgin.net>

3

Glynn Clements wrote:

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

I've gone through src/scripts and added calls to g.gisenv where
necessary.

More significantly, I've changed g.gisenv not to generate "export"
statements, and Init.sh not to export LOCATION, so anything which
expects to find GISDBASE, LOCATION_NAME, MAPSET or LOCATION in the
environment will fail.

With the exception of the monitor auto-redraw code, it should be
possible to switch GISDBASE/LOCATION_NAME/MAPSET mid-session.

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