[GRASS5] The status of 5.0

[Glynn Clements]

rgrmill at rt66.com wrote:

> 2)  As I wrote a couple months ago, I have a "resource manager" that 
> associates each monitor with a different geographic window and different 
> gis environment, including mapset and location.  There is associated 
> with that capability a module that allows the user to change the current 
> mapset and location without leaving grass and (hopefully) without 
> bothering anyone else working at the same time.  This allows one user to 
> work in multiple locations/mapsets at the same time.  The manager also 
> specifies certain types of system behavior; monitors are automatically 
> erased when their region is changed and removed when the user exits 
> grass.  The manager offers the kind of persistence and event-driven 
> behavior that we sometimes talk about needing for future development.  
> The manager, in one form or another, provides a lot of opportunities for 
> future development.
> 
> I still have one bug left to work out.  When it's done I'll submit a 
> description of the program and the working source code as a proposal.
> 
> It requires changes to put_window.c, get_window.c, env.c and d.mon.  

One of the main obstacles to switching location/mapset on the fly is
the number of scripts[1] which reference $GISDBASE, $LOCATION_NAME,
$MAPSET and/or $LOCATION directly.

Currently, these are set in Init.sh using "eval `g.gisenv`". There
isn't any way to subsequently change them using an external command;
using "eval" is inconvenient, and shell aliases/functions are messy
(non-portable, aren't inherited by scripts).

Shell scripts ought to be calling e.g. "eval `g.gisenv`" themselves to
obtain the current settings from $GISRC.

[1] AFAICT, I've fixed all of the C programs which accessed these
variables via getenv().

-- 
Glynn Clements <glynn.clements at virgin.net>