[GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser

this bug's URL: http://intevation.de/rt/webrt?serial_num=2488
-------------------------------------------------------------------------

Subject: GRASS 5.7 WISH - improve string reading ability in g.parser

grass binary for platform: MacOSX
GRASS Version: 5.7 26-03-2004

g.parser has difficulties parsing strings with spaces in them. If you enter a string with spaces, it treats each word as a separate, illegal entry for that variable. It doesn't make any difference if you try to quote it or not. The quotes seem to be automatically stripped away. This affects its ability to read SQL queries (it bombs out if you use AND, although this is permitted from the command line as long as you quote the query). It also makes it impossible to input column descriptions for v.in.ascii unless you go to the command line. There are other modules equally affected--usually those dealing with databases (although it also prevented me from doing a general purpose gdalwarp script because it won't parse a PROJ4 string). Any thoughts about how this could be fixed?

Michael Barton

-------------------------------------------- Managed by Request Tracker

Request Tracker wrote:

this bug's URL: http://intevation.de/rt/webrt?serial_num=2488

Subject: GRASS 5.7 WISH - improve string reading ability in g.parser

grass binary for platform: MacOSX
GRASS Version: 5.7 26-03-2004

g.parser has difficulties parsing strings with spaces in them. If you
enter a string with spaces, it treats each word as a separate, illegal
entry for that variable.

I can't reproduce this behaviour with 5.3, and g.parser itself is
unchanged in 5.7 (although G_parser() has some changes).

Are you sure that the problem isn't in the way that the GIS_OPT_*
variables are used in the script? Have you tried it with the test.sh
script from the g.parser directory? E.g.

  $ test.sh rast=fields vect=fields option1='hello world'
  
  Flag -f not set
  Value of GIS_OPT_option1: 'hello world'
  Value of GIS_OPT_raster: 'fields'
  Value of GIS_OPT_vect: 'fields'

--
Glynn Clements <glynn.clements@virgin.net>

> this bug's URL: http://intevation.de/rt/webrt?serial_num=2488
> Subject: GRASS 5.7 WISH - improve string reading ability in g.parser

..

> g.parser has difficulties parsing strings with spaces in them. If
> you enter a string with spaces, it treats each word as a separate,
> illegal entry for that variable.

I can't reproduce this behaviour with 5.3, and g.parser itself is
unchanged in 5.7 (although G_parser() has some changes).

I believe this will be the long standing problem in the TclTk menus,
which strips away all quotes from input fields.
Never found a solution to that, AFAIK.

Does it work as expected from the command line?

Hamish

Hamish wrote:

> > this bug's URL: http://intevation.de/rt/webrt?serial_num=2488
> > Subject: GRASS 5.7 WISH - improve string reading ability in g.parser
..
> > g.parser has difficulties parsing strings with spaces in them. If
> > you enter a string with spaces, it treats each word as a separate,
> > illegal entry for that variable.
>
> I can't reproduce this behaviour with 5.3, and g.parser itself is
> unchanged in 5.7 (although G_parser() has some changes).

I believe this will be the long standing problem in the TclTk menus,
which strips away all quotes from input fields.

Actually, the problem is deeper than that. You shouldn't *need* quotes
in input fields. And, unlike Bourne-shell, Tcl doesn't automatically
split variable values into words.

My guess is that something is flattening the argument list to a
string, then (implicitly) re-parsing it into a list, so embedded
spaces get treated as separators. E.g. doing:

  set list "$list $item"

(as you would in Bourne-shell), rather than using lappend.

Unlike Bourne-shell, Tcl has adequate support for preserving list
structure, by using braces where necessary. E.g.:

  set a "foo"
  set b "bar"
  set c "hello world"
  set list [list $a $b $c]
  puts $list
  
  => foo bar {hello world}

In any case, I'm pretty certain that this has nothing to do with
g.parser, in the sense that it applies equally to every program which
uses G_parser(), which is almost everything.

--
Glynn Clements <glynn.clements@virgin.net>