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

[Glynn Clements]

Cedric Shock wrote:

> > > parser.c now sets the OVERWRITE environment variable, but doesn't export
> > > it.
> 
> In bug 4331 you wrote:
> 
> > I would have thought that it would be sufficient for G_parser() to set
> > OVERWRITE itself if --o was used. That would then be inherited by the
> > script and by any modules which it calls.

Sorry. When I wrote that, I was under the impression that OVERWRITE
was an environment variable.

> Would this be G__setenv("OVERWRITE", "1") ?

That would work, but it's the wrong approach, as the change would be
persistent ...

> Or will something like:
> 
> r.patch --o ...
> r.in.gdal output=map_that_already_exists ...
> 
> overwrite the map_that_already_exists because the "env" changed?

Exactly.

> > More accurately, parser.c now sets the OVERWRITE environment variable
> > if either the OVERWRITE GRASS variable is set or if the --o switch is
> > used. It doesn't modify the OVERWRITE GRASS variable.
> 
> Is the above how to modify this like you suggested?

What I would suggest is to change G_parser() to:

1. Set the "overwrite" C variable if any of the following are
true:

a) The --o switch is used.
b) The OVERWRITE GRASS variable is set.
c) The OVERWRITE environment variable is set

2. Set the OVERWRITE environment variable from the "overwrite" C
variable.

1a) provides a means for the user to enable overwriting for a single
command. 1b) provides a means for the user to enable overwriting in a
persistent manner. 1c) provides a mechanism to make the --o switch to
do the right thing for scripts (and C programs which invoke other
modules via system(); there are a few of those).

More generally, environment variables should be used for parameters
where you might want a different setting for individual commands. Each
process has its own set of environment variables, but there is only
one set of GRASS variables.

OTOH, GRASS variables should be used where you want to be able to
enable or disable them for the session as a whole from a command. You
can't do this with environment variables, as only the shell can change
its own environment.

In terms of confusion between the two types of variables, it doesn't
help that the libgis functions which manipulate GRASS variables have
"env" in their names and are defined in a file called env.c (and the
documentation used to refer to them as "environment variables"; maybe
some still does?).

One of the biggest issues with integrating GRASS modules into a
higher-level architecture (e.g. the GUI) is the extensive use of state
stored in files (and the rather ad-hoc way in which this is done).

While this is a good idea from the perspective of a command-line
session (you wouldn't want to have to type database=... location=... 
mapset=... region=... for every command, along with monitor=... for
d.* commands), it's a nuisance if you want to be able to run multiple
commands concurrently (e.g. running commands from gis.m when the user
might also be running commands from the shell) or if you want multiple
contexts (e.g. one for each gis.m display).

Actually, the "fixes" have also been rather ad-hoc. It might be better
to do away with WIND and store the name of a saved region in $GISRC
instead, remove MONITOR_OVERRIDE and WIND_OVERRIDE, and just create an
alternate $GISRC file whenever you want to change any of those
parameters.

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