[GRASS-dev] r.colors confusion with "color", "rules", and "raster" options

[Glynn Clements]

Hamish wrote:

> I've just added some logic in 6.x SVN to more nicely handle different
> user interpretations of the commands. "accept sloppy input, create
> tight output" and all that. Sure 'color=rules rules=filename' is
> redundant, but the intention is obvious. some people (especially those
> unfamiliar) like to tick every box. if it doesn't hurt anything, let 'em.

Reverted.

If input is invalid, you report that it's invalid, not silently do
what you *think* that the user meant (i.e. DWIM).

If the user misunderstands something, you should educate them, not
reinforce the misconception.

> I also backported the effect of rules=- meaning read from stdin.

This is a reasonable enhancement.

> > -rules: create new color table based on user-specified rules
> > +rules: create new color table based on user-specified rules read from stdin
> 
> I reverted that as it is somewhat misleading. It can mean either read
> directly from stdin or if no stream is waiting then to enter into the
> interactive environment.

Huh? It always means "read from stdin". If stdin is a tty, you get the
interactive prompts; if it's a file or pipe, you don't.

I have re-instated the "read from stdin" text.

> traditionally (not to mention currently)
> color=rules in grass 5/6 triggered the interactive environment prompt
> and help menu. I see no reason to strongly push users to use the -i
> flag instead of color=rules when both are removed in GRASS 7.

-i doesn't come into it. In fact, -i could probably be removed from
6.4. It's a fairly recent addition, and it's unlikely to be of any use
in scripts, so it's unlikely that anything is actually relying upon
it.

> Just
> let the old way fade away gracefully in its own time without disrupting
> users. Where's the gain in intentionally scuttling it early?

This isn't about "scuttling" anything. colour=rules and rules= have
always been mutually exclusive, so long as rules= has existed.

Hopefully, we'll eventually have some way to communicate the
inter-relationships between options to the parser. In the meantime, we
should settle for communicating it to the user.

BTW, do we actually need to describe all of the color= options twice? 
The description.html file includes all of the options, but the
auto-generated portion already contains that information.

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