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 <[email protected]> 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 <[email protected]> _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
