[GRASS-dev] significant change in g.parser behavior for GRASS 7

[Glynn Clements]

Michael Barton wrote:

> I just learned that using upper case characters for a GRASS 7 module
> option means that g.parser will not recognize it.

Technically, the change is to G_parser(); g.parser simply inherits the
behaviour.

> That is for module. �r.foo" with options �Abc� and �def�, the
> command
> 
> r.foo Abc=1 def=2
> 
> will return an error <Abd=1> is not a valid option.

No it won't.

However, this will produce that error:

	r.foo def=2 Abc=1

If the first argument doesn't match the required syntax (e.g. because
of an upper-case character in the option name), it will be treated as
the value to the default (first) option. IOW, assuming that "Abc" is
the first option, your example:

	r.foo Abc=1 def=2

will be treated as:

	r.foo Abc=Abc=1 def=2

> GRASS 6 does not produce an error in this case. The module will run fine.
> 
> This breaks all kinds of existing scripts from GRASS6, as well as
> scripts that are designed to be chained together. I�ve never seen
> any discussion of this. Perhaps I missed it because I was in the
> field or something. Is there a reason for this significant change of
> g.parser behavior?

The changes in question are r32259 and r32261, from July 2008, and
r33576 from September 2008.

The rationale was related to changing r.mapcalc to use G_parser().

Following that change, if r.mapcalc is run as e.g.

	r.mapcalc "map=expression"

G_parser() will complain that there is no option named "map".

The preferred way of avoiding this issue is to place spaces around the
"=" sign; a space before the "=" guarantees that the argument will not
be treated as having the option=value form, and will instead be
treated as the value to the default option (expression=).

In order to maximise compatibility with the previous version, the test
for whether an argument has the option=value form was restricted. Any
argument not conforming to the (newly-restricted) syntax will be
treated as the value of the expression= option. The more restrictive
the syntax, the fewer expressions will be mistaken for option=value.

Originally, any argument containing an "=" was considered as having
the option=value form.

r32259 changed this to require that the character immediately before
the first "=" was not a space or tab. r32261 refined it to require the
character to be a lower-case letter or a digit. r33576 further refined
this so that the entire portion before the first "=" must consist
solely of lower-case letters, digits and underscores, and the
character immediately before the "=" must not be an underscore.

With one exception; all option names used in GRASS' own modules and
scripts already satisfied the new restrictions. The sole exception was
r.terraflow, which had the STREAM_DIR= option renamed to stream_dir=
in r32260.

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