[GRASS-user] can I access mapset outside of grass, by using python?

[Νίκος]

Hi Glynn!

 I've set-up my system based on your detailed descriptions/instructions
below (old post) using grass64.

1. Would you mind sharing in addition the way you change between
mapsets/locations? Do you start a new shell session after re-defining
somehow the variables LOCATION_NAME or/and MAPSET? Use just g.gisenv?

2. Also, I have compiled (but _not_ installed) grass65 and grass70 and
run them from "dist" directory, i.e. I launch grass70 via
"../grass_trunk/dist.x86_64-unknown-linux-gnu/grass70.tmp".

Now, I launch grass70 for testing, I try "d.mon" and I get:
---
Incompatible library version for module. You need to rebuild GRASS
       or untangle multiple installations.
---

I would expect the module not to be found at all since it doesn't exist
in grass70. Could this be a problem? Is there a way to lock-out all
other versions of grass-modules from being detectable when I am already
inside a grass70 session?

Thanks, Nikos


/----------------------------------------------------------------------/


On Fri, 2009-08-07 at 19:54 +0100, Glynn Clements wrote:
> The GRASS libraries require certain environment variables to be set. A
> "GRASS session" is just a set of processes (e.g. a shell and/or GUI)
> which have the necessary environment settings.
> 
> Specifically:
> 
> GISBASE needs to be set to the top-level directory of the GRASS
> installation.
> 
> GISRC needs to contain the absolute path to a file containing settings
> for GISDBASE, LOCATION_NAME and MAPSET.
> 
> PATH needs to include $GISBASE/bin and $GISBASE/scripts.
> 
> If the GRASS libraries are shared libraries, the loader needs to be
> able to find them. This normally means that LD_LIBRARY_PATH (Linux,
> Solaris), DYLD_LIBRARY_PATH (MacOSX) or PATH (Windows) need to contain
> $GISBASE/lib, although there are other means to the same end (e.g. on
> Linux, putting $GISBASE/lib (with $GISBASE replaced by its actual
> value) into /etc/ld.so.conf then running ldconfig).
> 
> Some libraries and modules use other variables. See the file
> $GISBASE/docs/html/variables.html for most of them (the display
> libraries used by d.* commands use additional variables, which are
> documented along with the individual drivers).
> 
> Personally, I have the following run from my ~/.bash_profile script:
> 
> 	export GISBASE=/usr/local/src/grass/svn/dist.i686-pc-linux-gnu
> 	export GRASS_GNUPLOT='gnuplot -persist'
> 	export GRASS_WIDTH=640
> 	export GRASS_HEIGHT=480
> 	export GRASS_HTML_BROWSER=firefox
> 	export GRASS_PAGER=cat
> 	export GRASS_WISH=wish
> 	export GRASS_PYTHON=python
> 	export GRASS_MESSAGE_FORMAT=silent
> 	export GRASS_TRUECOLOR=TRUE
> 	export GRASS_TRANSPARENT=TRUE
> 	export GRASS_PNG_AUTO_WRITE=TRUE
> 	
> 	export PATH="$GISBASE/bin:$GISBASE/scripts:$PATH"
> 	export LD_LIBRARY_PATH="$GISBASE/lib"
> 	export GRASS_LD_LIBRARY_PATH="$LD_LIBRARY_PATH"
> 	export PYTHONPATH="$GISBASE/etc/python:$PYTHONPATH"
> 	export MANPATH=$MANPATH:$GISBASE/man
> 	
> 	export GIS_LOCK=$$
> 	export GRASS_VERSION="7.0.svn"
> 	
> 	tmp=/tmp/grass6-"`whoami`"-$GIS_LOCK
> 	export GISRC="$tmp/gisrc"
> 	mkdir "$tmp"
> 	cp ~/.grassrc6 "$GISRC"
> 
> This allows GRASS commands to be used anywhere (my ~/.Xsession sources
> the bash startup scripts, so the settings aren't limited to
> interactive shells, but also work for e.g. M-! in XEmacs). Each
> interactive shell gets a separate "session" (i.e. a separate $GISRC
> file), while GUI programs share a common session.
> 
> The above is for GRASS 7, and uses the version from the dist.<arch>
> directory in the GRASS source tree rather than an installed version.
> 
> The only time I ever start GRASS explicitly is if I need to test
> changes to the startup scripts, or test a 6.x version.