[GRASSLIST:3270] Re: Wrestling with Grass5 env variables

[Glynn Clements]

Eric G. Miller wrote:

> > AFAICT, the complete set of environment variables which are set by the
> > "grass5" script and etc/Init.sh is:
> 
> [snip]
> 
> I think you forgot about the "eval g.gisenv", which may set quite
> a few more environment variables (depending on what's in ~/.grassrc5).

1. Initially, ~/.grassrc5 will only define GISDBASE, LOCATION_NAME,
and MAPSET.

2. The use of "eval `g.gisenv`" is mostly bogus. The settings which
are stored in this file (with G_setenv()) should be read using from
the file (with G_getenv()), rather from the environment.

AFAICT, there are two plausible reasons for reflecting the contents of
~/.grassrc into the environment:

a) A small number of programs[1] erroneously use getenv() instead of
using either G_getenv() or a more specific function (e.g. 
G_gisdbase(), G_location() etc). I'll fix any cases which I find.

b) Users may be confused by the way in which GRASS misuses the term
"environment variables" to refer to the settings which are stored in
$GISRC, and place environment variable definitions there rather than
in ~/.grass.bashrc or ~/.grass.cshrc.

In any case, the use of "eval `g.gisenv`" should be eliminated, as
it's eating into the command length limit (ARG_MAX).

[1] Specifically, v.merge and v.make.subj read GISDBASE and
LOCATION_NAME from the environment instead of $GISRC.

> > > I'm willing to take responsibility for cleaning up .tmp files.
> > > 
> > > What about concurrency issues, since I will not have a .gislock5
> > > file?
> > 
> > As well as writing to files within the current mapset, various
> > commands update the file specified by $GISRC. I suggest creating a new
> > file for each session, e.g.:
> 
> Concurrency might be an issue for edits/writes of data sets if two or
> more users are creating editing data in the same location.

Location? Or mapset?

I know that concurrent access to a single mapset is problematic, but
there shouldn't be a problem with separate mapsets in a single
location. Users shouldn't need (and shouldn't have) write permission
on the PERMANENT mapset.

> There's
> also the issue of the current region, which could create some real
> headaches.

That's definitely a mapset thing.

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