[GRASS-dev] Change in parser behavior?

Glynn Clements glynn at gclements.plus.com
Tue May 19 18:48:18 EDT 2009


C Michael Barton wrote:

> We've just encountered a strange change in the way the GRASS parser
> interacts with BASH. It's not clear whether it's the parser, BASH, or
> something else.
> 
> Previoiusly, if a GUI field was described as
> 
> #% type: string
> 
> ...whatever was entered was treated as a string, whether the entry was
> an alphabetic character string ("mymap") or a numeral ("50"). When the
> field was read, its value could be stored in a variable and then used.
> So entering 50 in an entry field defined as string would produce "50"
> when parsed.
> 
> Now, this doesn't seem to be the behavior of the parser and/or BASH.
> If 50 or "50" is entered into a field defined as #% type: string, it
> is ignored and the value of the parsed variable is empty, OR if there
> is a default value the default is used-even if the default value is
> numeric. So for the following entry from a BASH script..
> 
> #%option
> #% key: myfield
> #% type: string
> #% description: A string field
> #% required : yes
> 
> ...if 50 is entered, $GIS_OPT_MYFIELD is empty
> 
> If there is a default, as below...
> 
> #%option
> #% key: myfield
> #% type: string
> #% description: A string field
> #% required : yes
> #% answer : 1.5
> 
> ... and 50 is entered, $GIS_OPT_MYFIELD is 1.5
> 
> I have not yet tested this on the Mac, but it is showing up in GRASS
> 6.5 (of a couple weeks back) in Ubuntu ver. 9.
> 
> Has anyone else encountered this?

I can't see any changes to lib/gis/parser.c or general/g.parser which
could have caused this.

Are you testing this from the command line, or via one of the GUIs?

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


More information about the grass-dev mailing list