[GRASS-dev] [grass-code I][381] r.colors rules: some scripts broken

[Hamish]

Glynn Clements wrote:
> > you can get rid of the errors by changing "r.colors rules="
> > to "r.colors color=". I've just done this for r.in.srtm.
> > 
> > But really this will break a lot of scripts and should be revisited
> > to be backwards compatible. Suggestion: when it looks for the rules
> > file it should try looking for $GISBASE/etc/colors/$RULEFILE if it
> > can't find the file as just $RULEFILE.
> > 
> > Anything written using "r.colors rules=" will be affected.
> 
> When I added rules=, it was made clear that this was a temporary
> feature until it could replace color=.

I am happy for r.colors to evolve, and glad the rules files are now
finally merged into color=, but fear we will damage tons of user scripts
with this change.

"r.colors rules=" has been there for more than 3 years now, since before
the 6.0.0 release (5.3.0 and 5.7.0 too), and until recently the only way
to get at e.g. the srtm color rules, so widely used. All new rules since
then were added to rules= as it is so much easier than writing a new C
function for the old color= option.

> As there hasn't been a 6.3.0 release yet, the 6.3 API remains subject
> to change.

It is my understanding that module options are frozen for 6.x, not 6.x.y.
The idea being that a user script written for GRASS 6.0.0 will still
work with GRASS 6.9.99. Often an application is still in use at an
institution long after the original programmer/brain cells have moved on.

Would quietly checking for the file in $GISBASE/etc/colors/, after it
isn't found normally, really hurt much? (leaving that under-documented
in the help pages to discourage new use) We could flag it for removal
in GRASS7 if code clutter is a concern.


Hamish