<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Sep 25, 2014 at 11:56 PM, Michael Barton <span dir="ltr"><<a href="mailto:Michael.Barton@asu.edu" target="_blank">Michael.Barton@asu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.</blockquote><div><br></div><div>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.<br><br></div><div>More importantly, according to my understanding, reordering will not help you.<br><br></div><div>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).<br></div><div><br></div><div>Standard case:<br></div><div><br>./test_lower_lower.py elevation=abc slope=cde<br>{'slope': 'cde', 'elevation': 'abc'}<br><br></div><div>Both upper case, error reported for the second option. Error is not really informative but it fails.<br></div><div><br>./test_upper_upper.py Elevation=abc Slope=cde<br>ERROR: Sorry <Slope=cde> is not a valid option<br>ERROR: Required parameter <Slope> not set:<br> (Name for output slope raster map)<br><br></div><div>Same case as above, second option is not accepted (in this case the message at least applies to the first wrong option):<br></div><div><br>./test_lower_upper.py elevation=abc Slope=cde<br>ERROR: Sorry <Slope=cde> is not a valid option<br>ERROR: Required parameter <Slope> not set:<br> (Name for output slope raster map)<br><br></div><div>Only the first option is upper case and is accepted but the result is not what you would like to get:<br></div><div><br>./test_upper_lower.py Elevation=abc slope=cde<br>{'slope': 'cde', 'Elevation': 'Elevation=abc'}<br><br></div><div>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:<br></div><div><br>./test_upper_lower.py abc slope=cde<br>{'slope': 'cde', 'Elevation': 'abc'}<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">This makes it easier to maintain chaining between scripts or calling modules from other programs.</blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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.<br>
<span class="im"><br></span></blockquote><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="im">
Michael<br>
____________________<br>
C. Michael Barton<br>
Director, Center for Social Dynamics & Complexity<br>
Professor of Anthropology, School of Human Evolution & Social Change<br>
Head, Graduate Faculty in Complex Adaptive Systems Science<br>
Arizona State University<br>
<br>
voice: <a href="tel:480-965-6262" value="+14809656262">480-965-6262</a> (SHESC), <a href="tel:480-965-8130" value="+14809658130">480-965-8130</a>/727-9746 (CSDC)<br>
fax: <a href="tel:480-965-7671" value="+14809657671">480-965-7671</a> (SHESC), <a href="tel:480-727-0709" value="+14807270709">480-727-0709</a> (CSDC)<br>
www: <a href="http://www.public.asu.edu/~cmbarton" target="_blank">http://www.public.asu.edu/~cmbarton</a>, <a href="http://csdc.asu.edu" target="_blank">http://csdc.asu.edu</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
</span><div class=""><div class="h5">On Sep 25, 2014, at 4:40 PM, Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>> wrote:<br>
<br>
><br>
> Michael Barton wrote:<br>
><br>
>> I just learned that using upper case characters for a GRASS 7 module<br>
>> option means that g.parser will not recognize it.<br>
><br>
> Technically, the change is to G_parser(); g.parser simply inherits the<br>
> behaviour.<br>
><br>
>> That is for module. �r.foo" with options �Abc� and �def�, the<br>
>> command<br>
>><br>
>> r.foo Abc=1 def=2<br>
>><br>
>> will return an error <Abd=1> is not a valid option.<br>
><br>
> No it won't.<br>
><br>
> However, this will produce that error:<br>
><br>
> r.foo def=2 Abc=1<br>
><br>
> If the first argument doesn't match the required syntax (e.g. because<br>
> of an upper-case character in the option name), it will be treated as<br>
> the value to the default (first) option. IOW, assuming that "Abc" is<br>
> the first option, your example:<br>
><br>
> r.foo Abc=1 def=2<br>
><br>
> will be treated as:<br>
><br>
> r.foo Abc=Abc=1 def=2<br>
><br>
>> GRASS 6 does not produce an error in this case. The module will run fine.<br>
>><br>
>> This breaks all kinds of existing scripts from GRASS6, as well as<br>
>> scripts that are designed to be chained together. I�ve never seen<br>
>> any discussion of this. Perhaps I missed it because I was in the<br>
>> field or something. Is there a reason for this significant change of<br>
>> g.parser behavior?<br>
><br>
> The changes in question are r32259 and r32261, from July 2008, and<br>
> r33576 from September 2008.<br>
><br>
> The rationale was related to changing r.mapcalc to use G_parser().<br>
><br>
> Following that change, if r.mapcalc is run as e.g.<br>
><br>
> r.mapcalc "map=expression"<br>
><br>
> G_parser() will complain that there is no option named "map".<br>
><br>
> The preferred way of avoiding this issue is to place spaces around the<br>
> "=" sign; a space before the "=" guarantees that the argument will not<br>
> be treated as having the option=value form, and will instead be<br>
> treated as the value to the default option (expression=).<br>
><br>
> In order to maximise compatibility with the previous version, the test<br>
> for whether an argument has the option=value form was restricted. Any<br>
> argument not conforming to the (newly-restricted) syntax will be<br>
> treated as the value of the expression= option. The more restrictive<br>
> the syntax, the fewer expressions will be mistaken for option=value.<br>
><br>
> Originally, any argument containing an "=" was considered as having<br>
> the option=value form.<br>
><br>
> r32259 changed this to require that the character immediately before<br>
> the first "=" was not a space or tab. r32261 refined it to require the<br>
> character to be a lower-case letter or a digit. r33576 further refined<br>
> this so that the entire portion before the first "=" must consist<br>
> solely of lower-case letters, digits and underscores, and the<br>
> character immediately before the "=" must not be an underscore.<br>
><br>
> With one exception; all option names used in GRASS' own modules and<br>
> scripts already satisfied the new restrictions. The sole exception was<br>
> r.terraflow, which had the STREAM_DIR= option renamed to stream_dir=<br>
> in r32260.<br>
><br>
> --<br>
> Glynn Clements <<a href="mailto:glynn@gclements.plus.com">glynn@gclements.plus.com</a>><br>
<br>
_______________________________________________<br>
grass-dev mailing list<br>
<a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a></div></div></blockquote></div><br></div></div>