[GRASS-dev] [bug #4368] (grass) g.parser: pass through --o

[Glynn Clements]

Radim Blazek wrote:

> > > Of course, I moved it to G_get_window(). But then g.region -p
> > > prints WIND file, not GRASS_REGION variable, I am not sure
> > > what it should. Probably it should print GRASS_REGION?
> >
> > I would say so.
> >
> > g.region doesn't use G_get_window() to get the current region, but
> > uses:
> >
> >         if (G__get_window (&window, "", "WIND", G_mapset()) != NULL)
> >         {
> >                 G_get_default_window (&window);
> >                 G_put_window (&window);
> >         }
> >
> > The logic here is that if the WIND file is invalid, the only way to
> > set it is to run g.region, so so g.region can't just just call
> > G_get_window() (which will generate a fatal error if the WIND file is
> > invalid).
> >
> > Note that it does this before calling G_parser(), so that it can use
> > window.proj in the option definitions.
> >
> > After G_parser() returns, it replaces the region with the default
> > region if the -d flag is used, or with the named region if region= is
> > used. Otherwise, the previously-obtained region is retained and
> > modified according to the other options.
> >
> > There are a few possible solutions.
> >
> > One is to obtain the initial region using G_get_default_window().
> > After G_parser() returns, if the -d flag isn't given, it would use
> > G_get_window() to replace this with the current region. That would
> > allow the use of "g.region -d" to fix a missing/invalid WIND file,
> > while causing GRASS_REGION and WIND_OVERRIDE to work normally.
> >
> > The other is to explicitly test for GRASS_REGION and/or WIND_OVERRIDE
> > in g.region.
> 
> In theory the module should know nothing about GRASS_REGION.
> I would prefer the first possibility.
> In any case I am not going to work on g.region.

I'll implement the first solution in g.region.

> > > > For future development, I'm wondering if it would be a good idea to
> > > > replace the WIND file with a GRASS variable (e.g. REGION) using the
> > > > same syntax as GRASS_REGION.
> > >
> > > Do you mean GRASS mapset variable (in VAR)?
> >
> > Well, I meant that G_get_window() would become use G_getenv("REGION")
> > rather than G__get_window(..., "WIND"). It wouldn't really matter if
> > it was a mapset or GISRC variable; the main point was not to store
> > state in a form which can only have a single instance. Actually, the
> > same issue applies to the VAR file; what uses that? Just QGIS?
> 
> Standard GRASS variables (GISRC) are stored in  ~/.grassrc6
> and reloaded when a new mapset is opened. It does not make sense
> to store a region of one mapset and reload it in another one (which can be
> even in a different projection).
> 
> In VAR file are stored variables specific for the mapset. For example
> connection to database. It is not used by QGIS at all.

I see.

The point remains that using fixed files within the mapset directory
(WIND, VAR) means that you can only have one instance of that state
per mapset. That's fine for the historical "command-line session"
usage, but problematic for other cases.

The simplest fix is to repeat the hack used for WIND (provide an
environment variable to override it), but ultimately we need to
consider better mechanisms for saving state.

> > If all "session state" goes into $GISRC, you can just create a new
> > $GISRC file for each operation, without worrying about conflicts
> > (providing that the operations only read the data; supporting
> > concurrent modification is a long way off).
> 
> Yes, I like the idea, but we have to store the state of the last
> session for mapset somewhere. And the session state which includes
> WIND is mapset specific.

Actually, location-specific.

Ideally, all saved state should go into the user's home directory. 
Using the database directories creates obstacles for sharing the data
between multiple users. Even then, a single user should be able to
create multiple multiple instances of that state.

One option would be to give each location a unique ID at the point
that it is created (e.g. hash of hostname, pathname, current time) and
use that ID as a key in the user's saved state files (e.g. G_getenv()
would look for <key>:<variable> rather than just <variable>).

Simply using the pathname to the location directory as a key is
problematic if the directory is shared over a network and mounted at
different points on different hosts, as you wouldn't be able to re-use
the state files.

> > > I am using WIND as test for mapset in QGIS, exists another way
> > > to test if a directory in location is a mapset?
> >
> > You could test whether ../PERMANENT/DEFAULT_WIND exists. Or even just
> > whether ../PERMANENT exists.
> 
> I use that as location test, but location can contain directories
> which are not mapsets.

Presumably there's nothing stopping those directories containing a
file named WIND. Ultimately, you have to rely upon the user not to try
to use a non-mapset directory as a mapset. Also, we can just assert
that the manually adding arbitrary files or directories within a GRASS
database directory will result in undefined behaviour (i.e. we're
under no obligation to handle such cases).

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