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 <[email protected]>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 <[email protected]> > -- ****************************************** Jana Krajčovičová, PhD. Department of Air Quality Slovak Hydrometeorological Institute Jeséniova 17 831 01 Bratislava [email protected]
_______________________________________________ grass-user mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-user
