[GRASS-dev] GRASS 7 scripts overhaul

> Hamish wrote:
>> It tries to run grass.raster_history() without first testing
>> if the map is in the current mapset.

Glynn:

> Given that those maps are listed as inputs, it's debatable
> whether it should be modifying the history even if those
> maps are in the current mapset.

Markus M:

All that i.landsat.rgb does is creating color rules. They
are stored in /colr2 if the input maps are not in the current
mapset.
As r.colors does not modify the raster history, and
i.landsat.rgb is just a front-end for r.colors, one could
argue that i.landsta.rgb should not touch raster history as
well.

the point of storing the history is so that you can see the
non-obvious conditions which led to the map as it now exists, so
you can understand + recreate it. In that sense storing
i.landsat.rgb's info in the history is justified. (& basically
the entire point of having a history..)

Glynn redux:

> Given that those maps are listed as inputs,

As it modifies the map's metadata in-place, they should be
thought of as G_OPT_R_MAP instead of G_OPT_R_INPUT.
As the only thing which designates them as input maps in this
case is the "old" in the #%gisprompt field, I don't think we
have to worry about the finer semantics of "input=" vs. "map="

Hamish

Hamish wrote:

the point of storing the history is so that you can see the
non-obvious conditions which led to the map as it now exists, so
you can understand + recreate it. In that sense storing
i.landsat.rgb's info in the history is justified. (& basically
the entire point of having a history..)

specifically, for recording the state of the strength= and -p flag.
Unlike r.colors, it is not possible, even with a trained eye and
direct inspection of the colr/ file, to determine the input command
which created the present output.

Hamish