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

[Hamish]

> > > 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.

If the WIND file is bad/missing, g.region should fix it without
requiring a special have-to-look-for-it flag (as it does now), probably
with a warning about what it just did. Many modules give an error
("Invalid region, run g.region"). "Allow sloppy input, only give precise
output"


> 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.

Do "other cases" ensure data integrity? Or does that require something
ugly like lock files for each map? (e.g. made even worse: existing gis.m
problem of r.colors etc changes not triggering an updated PPM in the
display layer cache). I don't mind the restriction of one [read-write]
session per mapset. If I want to access a map I can always start in a
new mapset and call map at first_mapset [read-only].


> 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.

FWIW, I am a fan of retaining a WIND file per mapset.


> > > > 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.

No, but it's unlikely. Anything under the location dir is officially
part of the GRASS database, so people add stuff in there at their peril.
Tough luck.


> Ultimately, you have to rely upon the user not to try to use a
> non-mapset directory as a mapset.

The GUI startup screen will stop you if the mapset doesn't have a WIND
file (I'd prefer them greyed out on the mapset list). The text version
doesn't (it could; although text mode should probably be more permissive
& assume the user knows what they are doing).


> 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).

This is already true. (unasserted, but mucking with files in $GISDBASE
is at own risk)



Hamish