[GRASS-user] Using GRASS modules outside GRASS

[Jana Krajcovicova]

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
<gisdbase>/<location>/<mapset>, 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 at 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-<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>
>



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

jana.krajcovicova at shmu.sk
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/grass-user/attachments/20110810/4ae06282/attachment.html