[GRASS-user] Using GRASS modules outside GRASS

GRASS GRASS user
1

Hello,

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 …

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.
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?

I hope my narration is not too confusing :slight_smile:

Jana

–

Jana Krajčovičová, PhD.
Department of Air Quality
Slovak Hydrometeorological Institute
Jeséniova 17
831 01 Bratislava

jana.krajcovicova@shmu.sk

2

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@gclements.plus.com>

3

Thanks for your response, Glynn.
Now I see that the GIS_LOCK variable is not the name of the lock file created - it is a “parameter” for $GISBASE/etc/lock.
As I understand it, when GRASS is started normally, i.e. using grass63 -text //, the Init.sh file is run and all the environmental variables are set, inlcuding checking/creation of .gislock file.
When I use a grass module inside a script, Init.sh is not executed so all necessary env. variables need to be set either inside the script itself, or in system .bashrc file.
I’ve set the GIS_LOCK back to $$ (i.e., PID number). What happens is this: when I run a script containing GRASS modules, no Init.sh process is initiated so $GISBASE/etc/lock is not executed. Does it mean that I need to execute the $GISBASE/etc/lock explicitly inside my script?

Jana

On Wed, Aug 10, 2011 at 12:35 AM, Glynn Clements <glynn@gclements.plus.com> wrote:

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--/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@gclements.plus.com>

–

Jana Krajčovičová, PhD.
Department of Air Quality
Slovak Hydrometeorological Institute
Jeséniova 17
831 01 Bratislava

jana.krajcovicova@shmu.sk

4

Jana Krajcovicova wrote:

When I use a grass module inside a script, Init.sh is not executed so all
necessary env. variables need to be set either inside the script itself, or
in system .bashrc file.
I've set the GIS_LOCK back to $$ (i.e., PID number). What happens is this:
when I run a script containing GRASS modules, no Init.sh process is
initiated so $GISBASE/etc/lock is not executed. Does it mean that I need to
execute the $GISBASE/etc/lock explicitly inside my script?

Yes, if you want to lock the mapset for the duration of the script.

This is only really necessary if concurrent access may occur
automatically (without human intervention). Otherwise, you just need
to remember not run multiple concurrent commands in a single mapset.

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