Newsgroups: info.grass.user
Path: zorro.cecer.army.mil!shapiro
From: shapiro@zorro.cecer.army.mil (Michael Shapiro)
Subject: Re: gripes about .grassrc/env vars/locks/permissions
Message-ID: <CAFIHv.6qt@news.cecer.army.mil>
Sender: news@news.cecer.army.mil (Net.Noise owner)
Organization: US Army Corps of Engineers Construction Engineering Research Labs
References: <9307100922.AA26257@brier.ecn.purdue.edu>
Date: Mon, 19 Jul 1993 20:34:42 GMT
Lines: 30
In <9307100922.AA26257@brier.ecn.purdue.edu> mccauley@ecn.purdue.edu (Darrell McCauley) writes:
This is a "gotcha" - GRASS reads almost all of its info from $HOME/.grassrc
The Unix environment variables are constructed by GRASS for user convenience
but GRASS itself only uses 3 Unix env variables $GISBASE, $GISRC and $GIS_LOCK.
It has always worked this way. Also note, that even if you manage to
get two session running (ie have two distinct home directories on two machines)
you can still mess things up since GRASS gets the current region, and MASK,
among other info, from files in the current mapset.
I've run into a problem where if I run (concurrently) grass on two
separate machines and separate databases, things get screwed up ($HOME
and my data are both on the same filesystem, which is NFS mounted on both
machines). For example, programs like g.list seem to consult the
.grassrc file and not the environment variables. Should this be
happening? The grass4.1 startup script didn't prevent me from
running concurrent sessions.
I thought that (in the past) programs got information from your
shell's environment (e.g, $LOCATION). If the (current) design
philosophy is that GRASS should not be run concurrently anywhere by
any one user, then the current system does not work. (Are these
environment variables still needed if ~/.grassrc is always
consulted?)
--
Michael Shapiro shapiro@zorro.cecer.army.mil
U.S. Army CERL (217) 373-7277
P.O. Box 9005
Champaign, Ill. 61826-9005