No subject

[Net.Noise owner]

Newsgroups: info.grass.user
Path: zorro.cecer.army.mil!shapiro
From: shapiro at zorro.cecer.army.mil (Michael Shapiro)
Subject: Re: gripes about .grassrc/env vars/locks/permissions
Message-ID: <CAFIHv.6qt at news.cecer.army.mil>
Sender: news at news.cecer.army.mil (Net.Noise owner)
Organization: US Army Corps of Engineers Construction Engineering Research Labs
References: <9307100922.AA26257 at brier.ecn.purdue.edu>
Date: Mon, 19 Jul 1993 20:34:42 GMT
Lines: 30

In <9307100922.AA26257 at brier.ecn.purdue.edu> mccauley at 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 at zorro.cecer.army.mil
U.S. Army CERL                (217) 373-7277
P.O. Box 9005 
Champaign, Ill. 61826-9005