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

GRASS GIS GRASS GIS developer
1

I just learned that using upper case characters for a GRASS 7 module option means that g.parser will not recognize it. 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.

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?

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

2

On Wed, Sep 24, 2014 at 7:53 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

I just learned that using upper case characters for a GRASS 7 module
option means that g.parser will not recognize it. 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.

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?

I think that the lowercase options are a good choice. There are some
advantages of allowing uppercase like names of some coefficients (you can
have phi but also Phi, k and K) and abbreviation (HTML, PDF). However, I
think that the disadvantages are bigger. According to what I have seen,
with possibility to have both options (upper and lower case), people would
create options slope, but some other Slope, some perhaps even SLOPE. With
two words in the option name, it would be even worse: elevation_model,
ElevationModel, Elevation_model, Elevation_Model, ...

The consistency is not the only reason, we have there also Python and Bash
scripts. In Python, the option names are function parameters which in the
most Python coding styles should be lowercase (with or without underscores)
which is exactly what GRASS 7 parser wants. For Bash the situation is
different, we uppercase all the options (I believe in both 6 and 7) because
they are part of variable names, so of course we can do this only if we
know that all the letters have the same case, in 7 we know, they are
lowercase.

I don't think that occasional need for uppercase letters outweighs the
potential issues which would be potentially encountered by everyone.

Unfortunately, I'm not sure where is this documented and what was the
reason when it was introduced, from the logs it seems that the behavior was
introduced 6 year ago by Glynn:

http://trac.osgeo.org/grass/changeset/32261

I don't see any other place where the relevant check is done, so I think it
is this change. The check should be actually done when creating an option,
not when the option has a value (now it look like as an user error rather
then programmer's error).

Glynn, can you please comment on it?

Vaclav

Michael

           ____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

3

The issue is not about whether upper or lower case (or other characters) are good programming form or not in on language or another. This varies from context to context.

The issue is about a change in behavior of how GRASS scripts and modules are parsed between GRASS 6 and 7 that can cause unforseen problems for users when their scripts no longer run. I’m not convinced that aesthetics alone is a reason to break existing scripts that people may have written. There may well be other reasons. But if it is only aesthetics or is an unintended byproduct of some other change, we should consider fixing it.

Personally, I’d prefer that g.parser treats upper and lower case characters as equivalent in options (e.g., Kt = KT = kt = kT). That would avoid the possibility of confusion from having different options for Kt and kT, while not throwing an error if the user typed “kt” in any combination of case. Although there are common programming forms in Python, for example, it does not generate an error if upper or lower case is used.

At the very least, GRASS 7 should generate an error that says “upper case characters are not allowed in options names in GRASS 7”. The current error message, “<Abc=1> is not a valid option”, is ambiguous and misleading, as it suggests that the value is somehow incorrect or being parsed incorrectly.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Sep 24, 2014, at 7:34 PM, Vaclav Petras <wenzeslaus@gmail.com> wrote:

On Wed, Sep 24, 2014 at 7:53 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

I just learned that using upper case characters for a GRASS 7 module option means that g.parser will not recognize it. 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.

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?

I think that the lowercase options are a good choice. There are some advantages of allowing uppercase like names of some coefficients (you can have phi but also Phi, k and K) and abbreviation (HTML, PDF). However, I think that the disadvantages are bigger. According to what I have seen, with possibility to have both options (upper and lower case), people would create options slope, but some other Slope, some perhaps even SLOPE. With two words in the option name, it would be even worse: elevation_model, ElevationModel, Elevation_model, Elevation_Model, …

The consistency is not the only reason, we have there also Python and Bash scripts. In Python, the option names are function parameters which in the most Python coding styles should be lowercase (with or without underscores) which is exactly what GRASS 7 parser wants. For Bash the situation is different, we uppercase all the options (I believe in both 6 and 7) because they are part of variable names, so of course we can do this only if we know that all the letters have the same case, in 7 we know, they are lowercase.

I don’t think that occasional need for uppercase letters outweighs the potential issues which would be potentially encountered by everyone.

Unfortunately, I’m not sure where is this documented and what was the reason when it was introduced, from the logs it seems that the behavior was introduced 6 year ago by Glynn:

http://trac.osgeo.org/grass/changeset/32261

I don’t see any other place where the relevant check is done, so I think it is this change. The check should be actually done when creating an option, not when the option has a value (now it look like as an user error rather then programmer’s error).

Glynn, can you please comment on it?

Vaclav

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)

www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

4

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@gclements.plus.com>

5

Thanks for the explanation Glynn. So this is a byproduct of changes for other goals. It is good to learn that a work around can be simply re-odering the options. This makes it easier to maintain chaining between scripts or calling modules from other programs. This behavior is still a potential gotcha for anyone writing scripts, however. Sometimes it will give an ambiguous error and a similar script with a different order of options will not.

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Sep 25, 2014, at 4:40 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

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@gclements.plus.com>

6

On Thu, Sep 25, 2014 at 11:56 PM, Michael Barton <Michael.Barton@asu.edu>
wrote:

Thanks for the explanation Glynn. So this is a byproduct of changes for
other goals. It is good to learn that a work around can be simply
re-odering the options.

I would recommend not to work around thing like this. The behavior might be
changed in the future and you will be in the same or worse situation then
now.

More importantly, according to my understanding, reordering will not help
you.

I created four scripts. Each has two parameters/options "elevation" and
"slope". Script test_lower_lower has both options lowercase,
test_upper_upper has both options with uppercase letter etc. The output of
the script are the options (as Python dictionary).

Standard case:

./test_lower_lower.py elevation=abc slope=cde
{'slope': 'cde', 'elevation': 'abc'}

Both upper case, error reported for the second option. Error is not really
informative but it fails.

./test_upper_upper.py Elevation=abc Slope=cde
ERROR: Sorry <Slope=cde> is not a valid option
ERROR: Required parameter <Slope> not set:
    (Name for output slope raster map)

Same case as above, second option is not accepted (in this case the message
at least applies to the first wrong option):

./test_lower_upper.py elevation=abc Slope=cde
ERROR: Sorry <Slope=cde> is not a valid option
ERROR: Required parameter <Slope> not set:
    (Name for output slope raster map)

Only the first option is upper case and is accepted but the result is not
what you would like to get:

./test_upper_lower.py Elevation=abc slope=cde
{'slope': 'cde', 'Elevation': 'Elevation=abc'}

However, this is what r.mapcalc benefits from, for maximum compatibility in
the way the example above is showing and in standard cases in the way below:

./test_upper_lower.py abc slope=cde
{'slope': 'cde', 'Elevation': 'abc'}

This makes it easier to maintain chaining between scripts or calling
modules from other programs.

The changes are not more serious then changes in module parameters/options
and flags or module names and there is a lot of these changes between 6 and
7. Sorry, I really don't see much difference between other API changes and
this one.

This behavior is still a potential gotcha for anyone writing scripts,
however. Sometimes it will give an ambiguous error and a similar script
with a different order of options will not.

And this is exactly the reason why the lowercase should be enforced as

soon as possible in the parsing process or at least a better error message
should be provided. It would be good to avoid tests which would slow down
the correct scripts but I don't know if it would actually make any
difference.

Michael

____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Sep 25, 2014, at 4:40 PM, Glynn Clements <glynn@gclements.plus.com>
wrote:

>
> 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@gclements.plus.com>

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

(attachments)

test_upper_lower.py (515 Bytes)

7

It is good to see these tests. So order does not fix it like Glynn implied. It also gives different results depending on order and capitalization.

IMHO, this is a fairly serious problem. I’m OK with lower case being enforced but the way to do this that causes the least damage for porting scripts from GRASS 6 to GRASS 7 is for GRASS 7 to simply recognize all option names as lower case. That is option = lower(option).

The reason we found this is because we are porting to GRASS 7 a script that has worked in GRASS 6. We started getting the misleading error messages that you documented below.

At the very least, the error generated needs to be something along the lines of “upper case characters are not allowed for option names in GRASS modules”

Michael

···

On Thu, Sep 25, 2014 at 11:56 PM, Michael Barton <Michael.Barton@asu.edu> wrote:

Thanks for the explanation Glynn. So this is a byproduct of changes for other goals. It is good to learn that a work around can be simply re-odering the options.

I would recommend not to work around thing like this. The behavior might be changed in the future and you will be in the same or worse situation then now.

More importantly, according to my understanding, reordering will not help you.

I created four scripts. Each has two parameters/options “elevation” and “slope”. Script test_lower_lower has both options lowercase, test_upper_upper has both options with uppercase letter etc. The output of the script are the options (as Python dictionary).

Standard case:

./test_lower_lower.py elevation=abc slope=cde
{‘slope’: ‘cde’, ‘elevation’: ‘abc’}

Both upper case, error reported for the second option. Error is not really informative but it fails.

./test_upper_upper.py Elevation=abc Slope=cde
ERROR: Sorry <Slope=cde> is not a valid option
ERROR: Required parameter not set:
(Name for output slope raster map)

Same case as above, second option is not accepted (in this case the message at least applies to the first wrong option):

./test_lower_upper.py elevation=abc Slope=cde
ERROR: Sorry <Slope=cde> is not a valid option
ERROR: Required parameter not set:
(Name for output slope raster map)

Only the first option is upper case and is accepted but the result is not what you would like to get:

./test_upper_lower.py Elevation=abc slope=cde
{‘slope’: ‘cde’, ‘Elevation’: ‘Elevation=abc’}

However, this is what r.mapcalc benefits from, for maximum compatibility in the way the example above is showing and in standard cases in the way below:

./test_upper_lower.py abc slope=cde
{‘slope’: ‘cde’, ‘Elevation’: ‘abc’}

This makes it easier to maintain chaining between scripts or calling modules from other programs.

The changes are not more serious then changes in module parameters/options and flags or module names and there is a lot of these changes between 6 and 7. Sorry, I really don’t see much difference between other API changes and this one.

This behavior is still a potential gotcha for anyone writing scripts, however. Sometimes it will give an ambiguous error and a similar script with a different order of options will not.

And this is exactly the reason why the lowercase should be enforced as soon as possible in the parsing process or at least a better error message should be provided. It would be good to avoid tests which would slow down the correct scripts but I don’t know if it would actually make any difference.

Michael

C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Sep 25, 2014, at 4:40 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

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@gclements.plus.com>

grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev

8

Michael Barton wrote:

At the very least, the error generated needs to be something along
the lines of “upper case characters are not allowed for option names
in GRASS modules”

Right.

The current behaviour is a side-effect of the argument simply not
being considered as an option if the LHS of the = doesn't comply with
the requirements for option names.

Currently, the parser code doesn't perform any validation on the
options defined by the program. It attempts to detect run-time errors
arising from the user supplying invalid arguments; it doesn't attempt
to detect programming errors such as using an invalid name for an
option.

This wouldn't be particularly hard to do. Before processing argv,
G_parser() already iterates over the defined options to synchronise
the string and list-of-strings forms of the options, descriptions and
answers fields.

I'll add a check for invalid option names to that code.

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

9

Thanks Glynn

Michael
____________________
C. Michael Barton
Director, Center for Social Dynamics & Complexity
Professor of Anthropology, School of Human Evolution & Social Change
Head, Graduate Faculty in Complex Adaptive Systems Science
Arizona State University

voice: 480-965-6262 (SHESC), 480-965-8130/727-9746 (CSDC)
fax: 480-965-7671 (SHESC), 480-727-0709 (CSDC)
www: http://www.public.asu.edu/~cmbarton, http://csdc.asu.edu

On Sep 26, 2014, at 7:29 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

At the very least, the error generated needs to be something along
the lines of “upper case characters are not allowed for option names
in GRASS modules”

Right.

The current behaviour is a side-effect of the argument simply not
being considered as an option if the LHS of the = doesn't comply with
the requirements for option names.

Currently, the parser code doesn't perform any validation on the
options defined by the program. It attempts to detect run-time errors
arising from the user supplying invalid arguments; it doesn't attempt
to detect programming errors such as using an invalid name for an
option.

This wouldn't be particularly hard to do. Before processing argv,
G_parser() already iterates over the defined options to synchronise
the string and list-of-strings forms of the options, descriptions and
answers fields.

I'll add a check for invalid option names to that code.

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

10

Glynn Clements wrote:

I'll add a check for invalid option names to that code.

Done in r62105.

I wasn't sure whether it should be a warning or an error; for now it's
a warning.

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