[GRASSLIST:3270] Re: Wrestling with Grass5 env variables
glynn.clements at virgin.net
Fri Mar 1 08:00:31 EST 2002
Eric G. Miller wrote:
> > AFAICT, the complete set of environment variables which are set by the
> > "grass5" script and etc/Init.sh is:
> 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,
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 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).
 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.
> also the issue of the current region, which could create some real
That's definitely a mapset thing.
Glynn Clements <glynn.clements at virgin.net>
More information about the grass-user