[GRASS-user] Using GRASS modules outside GRASS

[Glynn Clements]

Jana Krajcovicova wrote:

> I would like to call GRASS modules from other programs - e.g. shell or perl.
> The information I found on grass wiki was a bit confusing for me,
> nevertheless I decided to test this possibility.
> I added GRASS environmental variables to my .bashrc file:
> 
> # path to GRASS binaries and libraries:
> export GISBASE=/usr/lib64/grass-6.3.0
> export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GISBASE/lib
> export GISRC=/home/mirka/grass/gisrc
> export GIS_LOCK=.gislock
> 
> Now, when I wrote a script, I create the gisrc file on the fly inside the
> script, specifying the location and mapset.
> Then I call a GRASS module, e.g., r.report, directly and it works fine.
> However, what bothers me, is the gislock, as it doesn't work properly -
> i.e., when I run the script outside GRASS it performs an operation on the
> specified location/mapset combination even in case the same combination of
> location/mapset is explicitly opened in another terminal.  I guess something
> is wrong with my specification of GIS_LOCK env. variable ...

GIS_LOCK should be a PID, not a filename. Specifically, it should be
the PID of a process which will exist for the lifetime of the session. 
You should use $GISBASE/etc/lock to create the .gislock file.

> I am not sure how this is supposed to operate, but what I observe is that
> the env. variables which I specify in .bashrc file, namely GISRC are only
> used for the modules called from scripts outside GRASS. When I open a
> location/mapset combination directly using grass, it creates gisrc file in
> /tmp/grass6-username-processID directory.

The startup script creates a new $GISRC file for each "session"; this
allows you to have multiple concurrent sessions. It copies ~/.grassrc6
to /tmp/grass6-<user>-<pid>/gisrc then sets GISRC to refer to that
file.

> As for the .gislock, I thought it should always be  located in the
> corresponding gisdbase/location/mapset directory. Then, why my scripts
> ingnore .gislock created by explicitly opened GRASS location/mapset?

Because your script isn't checking for a lock file. $GISBASE/etc/lock
checks for the existence of a lock file, and creates one if it doesn't
exist. It returns an exit code of 2 if a lock file already exists (and
the owner process is still running) and 0 if it created one
successfully (an exit code of 1 indicates some other error).

Also, if the PID stored in the lock file doesn't refer to an existing
process, the lock file is considered stale (the behaviour is as if no
lock file exists).

Look at $GIBASE/etc/Init.sh for more information on what is involved
in creating GRASS sessions.

-- 
Glynn Clements <glynn at gclements.plus.com>