Working with GRASS without starting it explicitly

From GRASS-Wiki
Revision as of 20:29, 6 April 2010 by NikosA (talk | contribs) (New page about accessing GRASS modules outside of a GRASS session)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

To be completed and formatted nicely!

GRASS sessions

It is possible to access GRASS modules without explicitly starting a "GRASS session". GRASS libraries require certain environment variables to be set. In fact 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 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/ then running ldconfig).

Some libraries and modules use other variables. More information for most of them is available in the file $GISBASE/docs/html/variables.html. The display libraries used by d.* commands use additional variables, which are documented along with the individual drivers.

Accessing GRASS modules without starting a GRASS session: an example under Linux

Below an example of a ~/.bash_profile script to set the required settings in order to access GRASS commands outside of a GRASS-session. Specifically it is for GRASS 7, and uses the version from the dist.<arch> directory in the GRASS source tree rather than an installed version.

       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 PATH="$GISBASE/bin:$GISBASE/scripts:$PATH"
       export LD_LIBRARY_PATH="$GISBASE/lib"
       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"

The above script will allow GRASS commands to be used anywhere. Furthermore, if the ~/.Xsession sources the bash startup scripts, 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.


Launching a grassXY session could still permit access on GRASS modules of the version that is set with the above script. The reason being is that grassXY scripts (e.g.: grass64, grass65, grass70) prepend the GRASS directories to PATH, LD_LIBRARY_PATH, etc. They won't remove any entries which are already there. A solution to this is to switch between GRASS versions by using a script like the following:

           for dir in $oldpath ; do
               case "${dir}" in
           echo "${newpath#:}"
       PATH=`strippath $PATH`
       export GISBASE=$PWD/dist.i686-pc-linux-gnu
       export PATH="$GISBASE/bin:$GISBASE/scripts:$PATH"
       export LD_LIBRARY_PATH="$GISBASE/lib"
       export PYTHONPATH="$GISBASE/etc/python"

Note: the above script needs to be "source"d; executing it won't work.

Important considerations (rename this title?)

Using normal grass sessions commands are recorded in /grassdb/location/mapset/.bash_history. While working with "pure" bash, shell entries go in ~/.bash_history. Merging existing "grass-bash_history(-ies)" with the bash history log, would probably be not a good idea. Perhaps it is wise(r) to use normal GRASS sessions when working on real projects. Nevertheless, it is upon the users preferences and expertise level to decide what is best.


  • Instructions and discussion on how to access GRASS mapsets outside of a GRASS session in the grass-user mailing list [1].