[GRASS-dev] g.mapset problems

Michael Barton michael.barton at asu.edu
Wed May 31 12:50:56 EDT 2006


Thanks Glynn. 

I've gotten around this (hopefully without hidden issues) by creating
procedures that use g.gisenv to change environmental settings for location
and mapset, and then changing TclTk global environmental variables
env(MAPSET) and env(LOCATION_NAME)--then changing them back. It seems to be
working pretty smoothly to get me in and back out of an xy location, though
it's not as straightforward as using g.mapset.

Any reason you think I should switch back to trying to make g.mapset work?

So I'm about 75% (I think) along the way to creating a pure TclTk
georectifying system.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton


> From: Glynn Clements <glynn at gclements.plus.com>
> Date: Wed, 31 May 2006 17:43:21 +0100
> To: Michael Barton <michael.barton at asu.edu>
> Cc: GRASS developers list <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] g.mapset problems
> 
> 
> Michael Barton wrote:
> 
>> I¹m trying to use g.mapset in a TclTk script and am having problems. I hope
>> that someone can help with this.
>> 
>> First, when I run it, it sends out text output stderror that seems to lock
>> it up if I try to redirect to /dev/null
> 
> No idea as to the cause, but if you add "2>&1" to the command, stderr
> will be redirected to stdout. That will prevent Tcl from treating it
> as an error.
> 
>> Second, if I try to run it to switch to a new location/mapset, and it
>> doesn¹t work, the next time I try to switch the same location/mapset, I get
>> the error...
>> 
>> ³cmbarton is currently running GRASS in selected mapset or lock file cannot
>> be checked.²
>> 
>> ...even if I am not working in that mapset. Does anyone know what is going
>> on?
> 
> It's possible that $GISBASE/etc/lock creates the .gislock file but
> returns a non-zero exit status, resulting in g.mapset not updating
> $GISRC. If that happens, the new mapset will be locked but won't be
> made the current mapset. Further attempts to switch to it will fail
> due to the lock.
> 
> Also, I note that the lock handing in etc/Init.sh assumes that the
> current mapset doesn't change throughout a session. I.e. when you exit
> GRASS, it deletes the .gislock file which was created at startup, not
> the one for the current mapset at termination time.
> 
> -- 
> Glynn Clements <glynn at gclements.plus.com>





More information about the grass-dev mailing list