[GRASS-user] Error running g.mapset

GRASS GRASS user
1

Greetings

I’m running WinGRASS and I’m obtaining a weird error when I run g.mapset:
ERROR: Unable to read GIS_LOCK environment variable

How can I fix this in Win GRASS?

Thanks

Best regards
Kat

2

On Thu, Oct 14, 2010 at 3:07 PM, katrin eggert
<katrineggert1980@gmail.com> wrote:

Greetings

I'm running WinGRASS and I'm obtaining a weird error when I run g.mapset:
ERROR: Unable to read GIS_LOCK environment variable

How can I fix this in Win GRASS?

I have seen

============
Author: glynn
Date: 2010-10-14 02:51:09 -0700 (Thu, 14 Oct 2010)
New Revision: 43906

Modified:
  grass/trunk/general/g.mapset/main.c
Log:
Don't set option defaults from current state (results in incorrect
documentation).

but I don't know if this is related nor if this should be backported.

Markus

3

Markus Neteler wrote:

> I'm running WinGRASS and I'm obtaining a weird error when I run g.mapset:
> ERROR: Unable to read GIS_LOCK environment variable
>
> How can I fix this in Win GRASS?

I have seen

============
Author: glynn
Date: 2010-10-14 02:51:09 -0700 (Thu, 14 Oct 2010)
New Revision: 43906

Modified:
  grass/trunk/general/g.mapset/main.c
Log:
Don't set option defaults from current state (results in incorrect
documentation).

but I don't know if this is related nor if this should be backported.

It's not related.

The underlying bug (init.bat doesn't set GIS_LOCK) is still present in
6.5-svn. It isn't applicable to 7.0, where init.sh/init.bat have been
replaced by a Python script (which does set GIS_LOCK).

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

4

On Sat, Oct 16, 2010 at 8:26 AM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

katrin eggert wrote:

I'm running WinGRASS and I'm obtaining a weird error when I run g.mapset:
ERROR: Unable to read GIS_LOCK environment variable

How can I fix this in Win GRASS?

...

The underlying bug (init.bat doesn't set GIS_LOCK) is still present in
6.5-svn. It isn't applicable to 7.0, where init.sh/init.bat have been
replaced by a Python script (which does set GIS_LOCK).

I have found this GPL program to the the PID which is needed
to set GIS_LOCK:
http://www.scheibli.com/projects/getpids/

Would that be of interest? Or is %RANDOM% together with something
else sufficient?

Markus

5

Markus Neteler wrote:

> The underlying bug (init.bat doesn't set GIS_LOCK) is still present in
> 6.5-svn. It isn't applicable to 7.0, where init.sh/init.bat have been
> replaced by a Python script (which does set GIS_LOCK).

I have found this GPL program to the the PID which is needed
to set GIS_LOCK:
http://www.scheibli.com/projects/getpids/

Would that be of interest? Or is %RANDOM% together with something
else sufficient?

AFAICT, GIS_LOCK needs to be set to an integer, but the actual value
is irrelevant on Windows.

g.mapset reads GIS_LOCK, passes it to $GISBASE/etc/lock, and checks
that etc/lock returns a zero exit code.

On Windows, etc/lock does nothing:

  int main(int argc, char *argv)
  {
  ...
      if (argc != 3 || sscanf(argv[2], "%d", &lockpid) != 1)
    G_fatal_error("usage: %s file pid", argv[0]);
  ...
  #ifdef __MINGW32__
      G_warning("Concurrent mapset locking is not supported on Windows");
      exit(0);
  #else

If GIS_LOCK isn't set, g.mapset will complain. If it doesn't parse
with "%d", etc/lock will complain. Other than that, it shouldn't
matter.

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

6

On Sat, Oct 16, 2010 at 3:32 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

> The underlying bug (init.bat doesn't set GIS_LOCK) is still present in
> 6.5-svn. It isn't applicable to 7.0, where init.sh/init.bat have been
> replaced by a Python script (which does set GIS_LOCK).

I have found this GPL program to the the PID which is needed
to set GIS_LOCK:
http://www.scheibli.com/projects/getpids/

Would that be of interest? Or is %RANDOM% together with something
else sufficient?

AFAICT, GIS_LOCK needs to be set to an integer, but the actual value
is irrelevant on Windows.

At this point, would adding this line suffice?

set GIS_LOCK=1

g.mapset reads GIS_LOCK, passes it to $GISBASE/etc/lock, and checks
that etc/lock returns a zero exit code.

On Windows, etc/lock does nothing:

   int main\(int argc, char \*argv\[\]\)
   \{
   \.\.\.
       if \(argc \!= 3 || sscanf\(argv\[2\], &quot;%d&quot;, &amp;lockpid\) \!= 1\)
           G\_fatal\_error\(&quot;usage: %s file pid&quot;, argv\[0\]\);
   \.\.\.
   \#ifdef \_\_MINGW32\_\_
       G\_warning\(&quot;Concurrent mapset locking is not supported on Windows&quot;\);
       exit\(0\);
   \#else

If GIS_LOCK isn't set, g.mapset will complain. If it doesn't parse
with "%d", etc/lock will complain. Other than that, it shouldn't
matter.

If there are no objections, I'll submit above.

Markus

7

Markus Neteler wrote:

> AFAICT, GIS_LOCK needs to be set to an integer, but the actual value
> is irrelevant on Windows.

At this point, would adding this line suffice?

set GIS_LOCK=1

AFAICT, yes.

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

8

On Sun, Oct 17, 2010 at 6:48 PM, Glynn Clements
<glynn@gclements.plus.com> wrote:

Markus Neteler wrote:

> AFAICT, GIS_LOCK needs to be set to an integer, but the actual value
> is irrelevant on Windows.

At this point, would adding this line suffice?

set GIS_LOCK=1

AFAICT, yes.

Done so in 6.4 and 6.5 (I don't know about 7).

@Katrin: you may just add this line in your local installation.

Markus