Thanks for your response, Glynn. <br>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. <br>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. <br>
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. <br>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? <br>
<br>Jana<br><br><br><div class="gmail_quote">On Wed, Aug 10, 2011 at 12:35 AM, Glynn Clements <span dir="ltr"><<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im"><br>
Jana Krajcovicova wrote:<br>
<br>
> I would like to call GRASS modules from other programs - e.g. shell or perl.<br>
> The information I found on grass wiki was a bit confusing for me,<br>
> nevertheless I decided to test this possibility.<br>
> I added GRASS environmental variables to my .bashrc file:<br>
><br>
> # path to GRASS binaries and libraries:<br>
> export GISBASE=/usr/lib64/grass-6.3.0<br>
> export PATH=$PATH:$GISBASE/bin:$GISBASE/scripts<br>
> export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$GISBASE/lib<br>
> export GISRC=/home/mirka/grass/gisrc<br>
> export GIS_LOCK=.gislock<br>
><br>
> Now, when I wrote a script, I create the gisrc file on the fly inside the<br>
> script, specifying the location and mapset.<br>
> Then I call a GRASS module, e.g., r.report, directly and it works fine.<br>
> However, what bothers me, is the gislock, as it doesn't work properly -<br>
> i.e., when I run the script outside GRASS it performs an operation on the<br>
> specified location/mapset combination even in case the same combination of<br>
> location/mapset is explicitly opened in another terminal. I guess something<br>
> is wrong with my specification of GIS_LOCK env. variable ...<br>
<br>
</div>GIS_LOCK should be a PID, not a filename. Specifically, it should be<br>
the PID of a process which will exist for the lifetime of the session.<br>
You should use $GISBASE/etc/lock to create the .gislock file.<br>
<div class="im"><br>
> I am not sure how this is supposed to operate, but what I observe is that<br>
> the env. variables which I specify in .bashrc file, namely GISRC are only<br>
> used for the modules called from scripts outside GRASS. When I open a<br>
> location/mapset combination directly using grass, it creates gisrc file in<br>
> /tmp/grass6-username-processID directory.<br>
<br>
</div>The startup script creates a new $GISRC file for each "session"; this<br>
allows you to have multiple concurrent sessions. It copies ~/.grassrc6<br>
to /tmp/grass6-<user>-<pid>/gisrc then sets GISRC to refer to that<br>
file.<br>
<div class="im"><br>
> As for the .gislock, I thought it should always be located in the<br>
> corresponding gisdbase/location/mapset directory. Then, why my scripts<br>
> ingnore .gislock created by explicitly opened GRASS location/mapset?<br>
<br>
</div>Because your script isn't checking for a lock file. $GISBASE/etc/lock<br>
checks for the existence of a lock file, and creates one if it doesn't<br>
exist. It returns an exit code of 2 if a lock file already exists (and<br>
the owner process is still running) and 0 if it created one<br>
successfully (an exit code of 1 indicates some other error).<br>
<br>
Also, if the PID stored in the lock file doesn't refer to an existing<br>
process, the lock file is considered stale (the behaviour is as if no<br>
lock file exists).<br>
<br>
Look at $GIBASE/etc/Init.sh for more information on what is involved<br>
in creating GRASS sessions.<br>
<font color="#888888"><br>
--<br>
Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
</font></blockquote></div><br><br clear="all"><br>-- <br>******************************************<br>Jana Krajčovičová, PhD.<br>Department of Air Quality<br>Slovak Hydrometeorological Institute<br>Jeséniova 17<br>831 01 Bratislava<br>
<br><a href="mailto:jana.krajcovicova@shmu.sk">jana.krajcovicova@shmu.sk</a><br><br><br>