[GRASS5] [bug #2402] (grass) r.colors - new rules=name option not yet working

[Glynn Clements]

Markus Neteler wrote:

> > > Subject: r.colors - new rules=name option not yet working
> > > 
> > > I tried the new rules=[filename] option. It generates ERROR: Unable to
> > > open rules file [filename]. Then it stops all processing until a
> > > ctrl-C is pressed. I tried a simple rules file:
> > > 
> > > 1 blue
> > > 2 green
> > > end
> > > 
> > > (I tried it with and without 'end' and got the same result)
> > 
> > The rules file needs to be in the $GISBASE/etc/colors/ directory. 
> 
> I have added the path to the message. Now the user knows where
> the file is searched:
> 
> r.colors N45E008.meters rules=test.rul
> ERROR: Unable to open rules file test.rul in
>        /nfsmnt/ssi0/ssi/neteler/grass57/dist.i686-pc-linux-gnu/etc/colors/test.rul

This is the wrong solution; a user doesn't need this information. A
better solution would be to list the set of valid options. If the list
was constructed and set as opt4->options, G_parser() would do this
automatically; however, the list could easily become quite large.

The original problem seems to stem from the user thinking that rules=
was meant for using user-supplied rule files. It isn't; color=rules
and shell redirection is the correct solution in that case. I'll fix
that problem by removing the word "file" from the option's
description, e.g.

    opt4->description = "name of predefined rule set";

rules= is meant to be analogous to color=, and may well be eliminated
in future (i.e. rules= will be renamed to color=). I just didn't want
to mess up the existing color= behaviour until the new code had some
testing and the "exceptions" (i.e. color=grey.eq/grey.log/random/rules)
had been dealt with.

-- 
Glynn Clements <glynn.clements at virgin.net>