[GRASS-dev] Change in parser behavior?

GRASS GRASS developer
1

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?

Michael

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

2

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

3

Glynn, we tested it from both guis as well as from the command line. Same issue every time. Those variables are not getting read in at all.

On Tue, May 19, 2009 at 3:48 PM, Glynn Clements <glynn@gclements.plus.com> wrote:

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

–

Isaac I Ullah, M.A.

Archaeology PhD Student,
ASU School of Evolution and Social Change

Research Assistant,
Mediterranean Landscape Dynamics Project

isaac.ullah@asu.edu
ullah@archaeologist.com

http://www.public.asu.edu/~iullah

4

We've tested on the command line and in both GUI's and are baffled. I've sent the script to Hamish to look at. It simply is ignoring data entered for some arguments. I can find no rhyme or reason to it. I thought it might be float data, but it doesn't seem to matter if we change the types to integer or string. We get the same lack of reading.

We've tried this on many versions of 6.5 from as far back as 30 March to today, and on a Linux (Ubuntu) and Mac system. Other scripts seem to work fine. I don't know if it is the number of arguments or something more insidious.

I tried cutting out all arguments except one, named "R" (R-factor for RUSLE), inserted an ...

echo "R=$GIS_OPT_R"

... and then ran the script on the command line

r.landscape.evol R=50

The terminal returned...

R=R=50

Go figure???

Michael

On 5/19/09 3:48 PM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

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

__________________________________________
Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of Human Evolution & Social Change
Center for Social Dynamics and Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton