[GRASS-user] can I access mapset outside of grass, by using
Wed Mar 3 20:44:23 EST 2010
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
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?
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.
> GISBASE needs to be set to the top-level directory of the GRASS
> 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"
> 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.
More information about the grass-user