[GRASS5] Re: [bug #2488] (grass) Transaction (glynn.clements@virgin.net)

Glynn,

Thanks much for responding so quickly. Here is what happens. If you just want to echo a string, it works OK. If you want to use the string as an argument to an option, it won't work. For example, look at d.vect. In the SQL box, you can put <field>=value and it works fine (no spaces). But you cannot put <field>=value and <field2>=value2. This generates an error that <field> value <field2> and value2 are illegal values--i.e., it treats each part of the argument as a separate entry. However you can do this on the command line with sql='<field>=value and <field2>=value2'.

I ran into this trying to do a script for gdalwarp. I just hit it again doing a script to make v.in.ascii read in a points file from a GUI interface. To specify column definitions you need to do

v.in.ascii .... columns='xcoord double,ycoord double,name varchar(10)' or something along that line.

This works from the command line. But in a g.parser GUI dialog, anything you put into am entry box for this variable gets parsed as a series of illegal entries rather than a single string argument. I've tried to quote it in the script, manually when I enter it, and other ways and have the same results.

Michael
______________________________
Michael Barton, Professor & Curator
School of Human Origins, Cultures, & Societies
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
On Jun 16, 2004, at 4:32 PM, Glynn Clements via RT wrote:

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

Thu, Jun 17 2004 01:32:48: Request 2488 was acted upon.

Transaction: Mail sent by glynn.clements@virgin.net

       Queue: grass
        Area: grass5.7
     Subject: GRASS 5.7 WISH - improve string reading ability in g.parser
       Owner:
  Requestors: michael.barton@asu.edu
      Status: open

-------------------------------------------------------------------------

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>

--- Headers Follow ---

From glynn.clements@virgin.net Thu Jun 17 01:32:48 2004

Return-Path: <glynn.clements@virgin.net>
Delivered-To: grass-bugs@lists.intevation.de
Received: from mail.intevation.de (aktaia [212.95.126.10])
  by lists.intevation.de (Postfix) with ESMTP id 045B5139C9
  for <grass-bugs@lists.intevation.de>; Thu, 17 Jun 2004 01:32:48 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1])
  by mail.intevation.de (Postfix) with ESMTP id 1273A36F10
  for <grass-bugs@lists.intevation.de>; Thu, 17 Jun 2004 01:32:49 +0200 (CEST)
Received: from n066.sc1.cp.net (h13.rdg.cp.net [209.228.29.63])
  by mail.intevation.de (Postfix) with ESMTP id 145A936E19
  for <grass-bugs@intevation.de>; Thu, 17 Jun 2004 01:32:47 +0200 (CEST)
Received: from cerise.nosuchdomain.co.uk (62.252.68.153) by n066.sc1.cp.net (7.0.027.3-1)
        id 40C8ED090009B97D; Wed, 16 Jun 2004 23:32:36 +0000
Received: (from glynn@localhost)
  by cerise.nosuchdomain.co.uk (8.11.6/8.11.6) id i5GNVED01602;
  Thu, 17 Jun 2004 00:31:14 +0100
From: Glynn Clements <glynn.clements@virgin.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <16592.55362.168057.819805@cerise.nosuchdomain.co.uk>
Date: Thu, 17 Jun 2004 00:31:14 +0100
To: Request Tracker <grass-bugs@intevation.de>
Cc: grass5@grass.itc.it
Subject: Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
In-Reply-To: <20040616222010.E1D3B13B4B@lists.intevation.de>
References: <20040616222010.E1D3B13B4B@lists.intevation.de>
X-Mailer: VM 7.07 under 21.4 (patch 15) "Security Through Obscurity" XEmacs Lucid
X-Spam-Status: No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
X-Spam-Level:

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

Michael Barton wrote:

Thanks much for responding so quickly. Here is what happens. If you
just want to echo a string, it works OK. If you want to use the string
as an argument to an option, it won't work. For example, look at
d.vect. In the SQL box, you can put <field>=value and it works fine (no
spaces). But you cannot put <field>=value and <field2>=value2. This
generates an error that <field> value <field2> and value2 are illegal
values--i.e., it treats each part of the argument as a separate entry.
However you can do this on the command line with sql='<field>=value and
<field2>=value2'.

I ran into this trying to do a script for gdalwarp. I just hit it again
doing a script to make v.in.ascii read in a points file from a GUI
interface. To specify column definitions you need to do

v.in.ascii .... columns='xcoord double,ycoord double,name varchar(10)'
or something along that line.

This works from the command line. But in a g.parser GUI dialog,
anything you put into am entry box for this variable gets parsed as a
series of illegal entries rather than a single string argument. I've
tried to quote it in the script, manually when I enter it, and other
ways and have the same results.

First, are we talking about g.parser or G_parser()?

If the problem is with the Tcl/Tk dialogs, that's probably a bug in
G_gui(). ISTR that tcltkgrass suffers from the same problem.

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