Thu, Jun 17 2004
00:20:10
|
|
Request created by guest
|
|
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 |
|
Thu, Jun 17 2004
01:32:48
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
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 |
|
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>
|
|
Thu, Jun 17 2004
01:55:59
|
|
Mail sent by michael.barton@asu.edu
|
|
Return-Path |
<michael.barton@asu.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 16 Jun 2004 16:55:27 -0700
|
From |
Michael Barton <michael.barton@asu.edu>
|
Subject |
Re: [bug #2488] (grass) Transaction (glynn.clements@virgin.net)
|
In-reply-to |
<20040616233248.90C6313B55@lists.intevation.de>
|
To |
Glynn Clements via RT <grass-bugs@intevation.de>
|
Cc |
GRASS5 list <grass5@grass.itc.it>
|
Message-id |
<A4320528-BFF0-11D8-BD27-000A95953870@asu.edu>
|
MIME-version |
1.0 (Apple Message framework v618)
|
X-Mailer |
Apple Mail (2.618)
|
Content-type |
text/plain; charset=US-ASCII; delsp=yes; format=flowed
|
Content-transfer-encoding |
7bit
|
References |
<20040616233248.90C6313B55@lists.intevation.de>
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
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
|
|
Thu, Jun 17 2004
09:16:00
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Thu, 17 Jun 2004 19:15:32 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Glynn Clements <glynn.clements@virgin.net>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
Message-Id |
<20040617191532.0fb43cc9.hamish_nospam@yahoo.com>
|
In-Reply-To |
<16592.55362.168057.819805@cerise.nosuchdomain.co.uk>
|
References |
<20040616222010.E1D3B13B4B@lists.intevation.de> <16592.55362.168057.819805@cerise.nosuchdomain.co.uk>
|
X-Mailer |
Sylpheed version 0.9.10 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-scanner |
scanned by Inflex 1.0.12.7
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> > 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
|
|
Thu, Jun 17 2004
13:07:05
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16593.29989.403062.160747@cerise.nosuchdomain.co.uk>
|
Date |
Thu, 17 Jun 2004 11:40:37 +0100
|
To |
Michael Barton <michael.barton@asu.edu>
|
Cc |
Glynn Clements via RT <grass-bugs@intevation.de>, GRASS5 list <grass5@grass.itc.it>
|
Subject |
Re: [GRASS5] Re: [bug #2488] (grass) Transaction (glynn.clements@virgin.net)
|
In-Reply-To |
<A4320528-BFF0-11D8-BD27-000A95953870@asu.edu>
|
References |
<20040616233248.90C6313B55@lists.intevation.de> <A4320528-BFF0-11D8-BD27-000A95953870@asu.edu>
|
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 |
|
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>
|
|
Thu, Jun 17 2004
13:07:08
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16593.30790.437059.9042@cerise.nosuchdomain.co.uk>
|
Date |
Thu, 17 Jun 2004 11:53:58 +0100
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
In-Reply-To |
<20040617191532.0fb43cc9.hamish_nospam@yahoo.com>
|
References |
<20040616222010.E1D3B13B4B@lists.intevation.de> <16592.55362.168057.819805@cerise.nosuchdomain.co.uk> <20040617191532.0fb43cc9.hamish_nospam@yahoo.com>
|
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 |
|
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>
|
|
Fri, Jun 18 2004
06:42:23
|
|
Mail sent by michael.barton@asu.edu
|
|
Return-Path |
<michael.barton@asu.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
In-Reply-To |
<20040617110708.BE630139F0@lists.intevation.de>
|
References |
<20040617110708.BE630139F0@lists.intevation.de>
|
Mime-Version |
1.0 (Apple Message framework v618)
|
Content-Type |
text/plain; charset=US-ASCII; format=flowed
|
Message-Id |
<D8CD04A3-C0E1-11D8-9874-000A956FE2E0@asu.edu>
|
Content-Transfer-Encoding |
7bit
|
Cc |
grass5@grass.itc.it
|
From |
Michael Barton <michael.barton@asu.edu>
|
Subject |
Re: [bug #2488] (grass) GRASS 5.7 WISH - improve string
|
Date |
Thu, 17 Jun 2004 21:42:04 -0700
|
To |
Glynn Clements via RT <grass-bugs@intevation.de>
|
X-Mailer |
Apple Mail (2.618)
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
Glynn,
Your description below sounds like what is indeed happening. My
confusion over where it is taking place is because the tcl parser
(i.e., the apparent location of this behavior) is described in the
documentation under g.parser.
It's not quite clear to me how I can work around this in a bash script.
Sorry if I'm dense here. How do I make sure that a multi-item argument,
of unknown length, that a user inputs will be read as a single argument
and not a list of separate items when the relevant GRASS (or other)
command is actually parsed? Assuming that I can put this in the scripts
where it is necessary, can it be remedied in the C++ GRASS modules
(primarily those that have an SQL query string as argument)?
Thanks for your help.
Michael
____________________
C. Michael Barton, Professor
School of Human Origins, Cultures, & Societies
PO Box 872402
Arizona State University
Tempe, AZ 85287-2402
USA
Phone: 480-965-6262
Fax: 480-965-7671
www: <www.public.asu.edu/~cmbarton>
On Jun 17, 2004, at 4:07 AM, Glynn Clements via RT wrote:
> 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.
|
|
Mon, Aug 2 2004
13:06:47
|
|
Comments added by guest
|
|
Cc: grass5@grass.itc.it
adding printf("argc=%d\n", argc); to G_parser() highlights the problem
e.g. 5.7's auto-gen Tcl makes:
button .run -text "Run" -command {
...
set cmd "| $cmd 2>@ stdout"
catch {open $cmd r} msg
...
}
so:
set cmd {d.text.freetype text="abc 123" path=font.ttf}
gives argc=4 in G_parser
argv[0] is 'd.text.freetype'
argv[1] is 'text="abc'
argv[2] is '123"'
argv[3] is 'path=font.ttf'
and
set cmd {d.text.freetype text="abc_123" path=font.ttf}
gives argc=3 (and works)
so it is never filtered through a shell for option="a b" to be made one item.
The $cmd string is formed correctly; but not passed to G_parser() correctly.
Hamish
|
|
Tue, Aug 3 2004
02:20:40
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16654.54697.476175.920469@cerise.nosuchdomain.co.uk>
|
Date |
Tue, 3 Aug 2004 01:00:41 +0100
|
To |
guest user via RT <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 |
<20040802110647.C370513B16@lists.intevation.de>
|
References |
<20040802110647.C370513B16@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 |
|
guest user via RT wrote:
> e.g. 5.7's auto-gen Tcl makes:
> button .run -text "Run" -command {
> ...
> set cmd "| $cmd 2>@ stdout"
> catch {open $cmd r} msg
> ...
> }
A good example of how *not* to to construct command lines in Tcl (or,
for that matter, most languages).
A Unix command consists of a list of strings, not a single string.
There are defined boundaries between arguments, and these need to be
preserved. Fortunately, Tcl's open and exec functions accept Tcl
lists, which makes this relatively easy to achieve (unlike e.g.
system()).
Tcl lists should be constructed and manipulated using the appropriate
functions, e.g. list, lappend, concat etc. They should not be
constructed by including variable expansions in a double-quoted
string.
E.g. in the above, the line:
set cmd "| $cmd 2>@ stdout"
should be written as:
set cmd [concat | $cmd 2>@ stdout]
I.e.:
$ tclsh
% set cmd {d.text.freetype {text=abc 123} path=font.ttf}
$ puts $cmd
d.text.freetype {text=abc 123} path=font.ttf
% foreach x $cmd {puts $x}
d.text.freetype
text=abc 123
path=font.ttf
% set cmd [concat | $cmd 2>@ stdout]
% puts $cmd
| d.text.freetype {text=abc 123} path=font.ttf 2>@ stdout
% foreach x $cmd {puts $x}
|
d.text.freetype
text=abc 123
path=font.ttf
2>@
stdout
%
However, that specific change will only help if the original value of
$cmd is already a well-formed list (i.e. where "text=abc 123" is a
single item rather than a pair of items). Given that most of the Tcl
command-line handling (in both tcltkgrass and G_gui()) which I have
seen is similarly broken, there are probably other places which also
need to be fixed.
> so:
> set cmd {d.text.freetype text="abc 123" path=font.ttf}
> gives argc=4 in G_parser
>
> argv[0] is 'd.text.freetype'
> argv[1] is 'text="abc'
> argv[2] is '123"'
> argv[3] is 'path=font.ttf'
Which is correct. You've set cmd to a list which contains four
elements, which correspond to the four argv[] values above.
> and
>
> set cmd {d.text.freetype text="abc_123" path=font.ttf}
> gives argc=3 (and works)
>
> so it is never filtered through a shell for option="a b" to be made one item.
> The $cmd string is formed correctly; but not passed to G_parser() correctly.
No it isn't formed correctly. exec (and open where the first word is
the pipe symbol) treat their argument as a *list*, not a string. Well,
everything in Tcl is a string, but it has specific semantics for
strings which represent lists, i.e. any elements which contain spaces
will be contained within braces.
If you construct the *list* using list manipulation functions such as
list, lappend, concat etc, Tcl will preserve the list structure. E.g.
% set arg1 {d.text.freetype}
% set arg2 {text=abc 123}
% set arg3 {path=font.ttf}
% set string "$arg1 $arg2 $arg3"
% puts $string
d.text.freetype text=abc 123 path=font.ttf
% foreach x $string {puts $x}
d.text.freetype
text=abc
123
path=font.ttf
% set list [list $arg1 $arg2 $arg3]
% puts $list
d.text.freetype {text=abc 123} path=font.ttf
% foreach x $list {puts $x}
d.text.freetype
text=abc 123
path=font.ttf
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Tue, Aug 3 2004
09:43:53
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 3 Aug 2004 19:43:27 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Glynn Clements <glynn.clements@virgin.net>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it, michael.barton@asu.edu
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
Message-Id |
<20040803194327.022ae4e7.hamish_nospam@yahoo.com>
|
In-Reply-To |
<16654.54697.476175.920469@cerise.nosuchdomain.co.uk>
|
References |
<20040802110647.C370513B16@lists.intevation.de> <16654.54697.476175.920469@cerise.nosuchdomain.co.uk>
|
X-Mailer |
Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> Tcl lists should be constructed and manipulated using the appropriate
> functions, e.g. list, lappend, concat etc. They should not be
> constructed by including variable expansions in a double-quoted
> string.
Ok, thanks for the tips Glynn.
I changed append-> lappend in some places and now it is all working,
AFAICT. (& in CVS)
Using special chars ( []{}"$@ ) in the text input box works correctly.
Anybody know of anywhere else it breaks?
e.g. 5.3; d.m; v.digit settings; startup TclTk screen; etc.
cheers,
Hamish
|
|
Tue, Aug 3 2004
17:45:19
|
|
Mail sent by michael.barton@asu.edu
|
|
Return-Path |
<Michael.Barton@asu.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 03 Aug 2004 08:44:51 -0700
|
From |
Michael Barton <michael.barton@asu.edu>
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
In-reply-to |
<20040803194327.022ae4e7.hamish_nospam@yahoo.com>
|
To |
Hamish <hamish_nospam@yahoo.com>, Glynn Clements <glynn.clements@virgin.net>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Message-id |
<BD350103.2593%michael.barton@asu.edu>
|
MIME-version |
1.0
|
Content-type |
text/plain; charset=US-ASCII
|
Content-transfer-encoding |
7bit
|
User-Agent |
Microsoft-Entourage/11.0.0.040405
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On 8/3/04 12:43 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
> Ok, thanks for the tips Glynn.
>
> I changed append-> lappend in some places and now it is all working,
> AFAICT. (& in CVS)
>
>
> Using special chars ( []{}"$@ ) in the text input box works correctly.
>
>
> Anybody know of anywhere else it breaks?
> e.g. 5.3; d.m; v.digit settings; startup TclTk screen; etc.
>
Hamish,
Does this mean that the G.PARSER() problem is generally fixed and we can
enter strings with spaces into the tcl dialogs? Hallelujah! Thanks to both
of you!
The same problem affected d.m in the places to do SQL queries.
It also affected the v.digit startup where you specify a command to provide
a background map. Once you are in v.digit, it is then possible to specify a
background map.
It may (or may not) also be related to NVIZ not starting from the
autogenerated GUI. Currently, you have to start NVIZ from the command line
using the -q switch, then add data after it is running. That is, you can't
specify initial raster, vector, ect. files in the startup GUI dialog. If you
try to start NVIZ this way, it will crash.
I don't remember running into this in 5.3, but the GUI is very different in
5.3; G.PARSER() works but doesn't autogenerate the dialog boxes. They are
each coded individually.
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
|
|
Wed, Aug 4 2004
03:06:33
|
|
Mail sent by hamish_nospam@yahoo.com
|
|
Return-Path |
<hamish_nospam@yahoo.com>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 4 Aug 2004 13:06:08 +1200
|
From |
Hamish <hamish_nospam@yahoo.com>
|
To |
Michael Barton <michael.barton@asu.edu>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
Message-Id |
<20040804130608.28360ccf.hamish_nospam@yahoo.com>
|
In-Reply-To |
<BD350103.2593%michael.barton@asu.edu>
|
References |
<20040803194327.022ae4e7.hamish_nospam@yahoo.com> <BD350103.2593%michael.barton@asu.edu>
|
X-Mailer |
Sylpheed version 0.9.12 (GTK+ 1.2.10; i386-pc-linux-gnu)
|
X-Face |
M<EoB)"*Z~u!,vFhXmw}R_KbdBta*P_=T|rbBL'e1/CQ9;/1g\BU3&!=y8ria$2Uk!HT&BB 8i?|X_+7~1jsy}F~g$2va%3fV`*=L(*cem[@3\yg,G,@rg6/QMJ
|
Mime-Version |
1.0
|
Content-Type |
text/plain; charset=US-ASCII
|
Content-Transfer-Encoding |
7bit
|
X-Spam-Status |
No, hits=-4.0 tagged_above=-999.0 required=3.0 tests=BAYES_00, FORGED_YAHOO_RCVD
|
X-Spam-Level |
|
> > I changed append-> lappend in some places and now it is all working,
> > AFAICT. (& in CVS)
...
> Does this mean that the G.PARSER() problem is generally fixed and we
> can enter strings with spaces into the tcl dialogs?
yup.
> The same problem affected d.m in the places to do SQL queries.
works. (Add vector->SQL Query)
> It also affected the v.digit startup where you specify a command to
> provide a background map. Once you are in v.digit, it is then possible
> to specify a background map.
works. (just another Tcl startup menu like all the rest)
> It may (or may not) also be related to NVIZ not starting from the
> autogenerated GUI. Currently, you have to start NVIZ from the command
> line using the -q switch, then add data after it is running. That is,
> you can't specify initial raster, vector, ect. files in the startup
> GUI dialog. If you try to start NVIZ this way, it will crash.
still broken:
can not find channel named "couldn't execute "nviz2.2_script": no such
file or directory"
> I don't remember running into this in 5.3,
It was a problem in 5.3, but without the SQL queries it only affects the
d.text modules AFAIK. Fixed in CVS. Both the 5.3 and 5.7 changes make
the shell command preview un-cut&paste-able for things with spaces in
them, but this never worked before either.. some fancy formatting before
printing the text string could probably move & replace the {}s to "s if
someone was keen to try.
The error is still in grass51/gui/tcltkgrass/main/gui.tcl but that is
in now unused code which should be ripped out???
Hamish
|
|
Wed, Aug 4 2004
03:50:43
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16656.16192.991231.825726@cerise.nosuchdomain.co.uk>
|
Date |
Wed, 4 Aug 2004 02:43:28 +0100
|
To |
Michael Barton <michael.barton@asu.edu>
|
Cc |
Hamish <hamish_nospam@yahoo.com>, grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
In-Reply-To |
<BD350103.2593%michael.barton@asu.edu>
|
References |
<20040803194327.022ae4e7.hamish_nospam@yahoo.com> <BD350103.2593%michael.barton@asu.edu>
|
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 |
|
Michael Barton wrote:
> It may (or may not) also be related to NVIZ not starting from the
> autogenerated GUI. Currently, you have to start NVIZ from the command line
> using the -q switch, then add data after it is running. That is, you can't
> specify initial raster, vector, ect. files in the startup GUI dialog. If you
> try to start NVIZ this way, it will crash.
I'm fairly sure that particular issue isn't related to Tcl/Tk. The
reports of NVIZ crashing unless you use -q indicate that it crashes if
you specify the arguments on the command line, e.g. "nviz elevation=...",
where Tcl/Tk isn't involved.
> I don't remember running into this in 5.3, but the GUI is very different in
> 5.3; G.PARSER() works but doesn't autogenerate the dialog boxes. They are
> each coded individually.
The 5.0/5.3 problems are essentially the same bugs, but in different
code. 5.0/5.3 has tcltkgrass, which is a self-contained Tcl/Tk program
which works by executing GRASS commands.
In 5.7, the problems are in G_gui(), which is called by G_parser(),
which is used by most commands to parse the command line. In 5.0/5.3,
if a command was run without arguments, G_parser() would ask the user
for the infomation via the terminal. In 5.7, it generates and runs a
Tcl/Tk program which displays a dialog, then re-executes the command
using the data from the dialog fields as arguments.
In both cases, you have Tcl/Tk code which attempts to construct and
execute a command line; in both cases, the code was wrong, for
essentially the same reasons.
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Wed, Aug 4 2004
04:39:00
|
|
Mail sent by glynn.clements@virgin.net
|
|
Return-Path |
<glynn.clements@virgin.net>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
From |
Glynn Clements <glynn.clements@virgin.net>
|
MIME-Version |
1.0
|
Content-Type |
text/plain; charset=us-ascii
|
Content-Transfer-Encoding |
7bit
|
Message-ID |
<16656.19420.187964.331736@cerise.nosuchdomain.co.uk>
|
Date |
Wed, 4 Aug 2004 03:37:16 +0100
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
Michael Barton <michael.barton@asu.edu>, grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
In-Reply-To |
<20040804130608.28360ccf.hamish_nospam@yahoo.com>
|
References |
<20040803194327.022ae4e7.hamish_nospam@yahoo.com> <BD350103.2593%michael.barton@asu.edu> <20040804130608.28360ccf.hamish_nospam@yahoo.com>
|
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 |
|
Hamish wrote:
> > It may (or may not) also be related to NVIZ not starting from the
> > autogenerated GUI. Currently, you have to start NVIZ from the command
> > line using the -q switch, then add data after it is running. That is,
> > you can't specify initial raster, vector, ect. files in the startup
> > GUI dialog. If you try to start NVIZ this way, it will crash.
>
> still broken:
> can not find channel named "couldn't execute "nviz2.2_script": no such
> file or directory"
Oh. That *is* a Tcl issue.
The immediate error arises from this code in G_gui():
catch {open $cmd r} msg
fconfigure $msg -blocking 0
fileevent $msg readable [ list prnout $msg ]
If the open command succeeds, catch will set msg to the result from
the command (i.e. the channel ID) and return 0. If the command fails,
catch will set msg to the error message and return non-zero.
IOW, msg will only contain a valid channel ID if catch returns zero,
so the above code should probably look something like:
if {[catch {open $cmd r} msg]} {
error $msg
} {
fconfigure $msg -blocking 0
fileevent $msg readable [ list prnout $msg ]
}
[Or even just omit the call to catch, so that any errors are
propagated via Tcl's normal error handling mechanism.]
At least, that will handle errors correctly.
As for the actual error, that's because G_gui() is using the value of
argv[0] from G_parser(), and argv[0] is "nviz2.2_script", which isn't
an executable file.
For G_gui() to work correctly, NVWISH2.2 needs to call G_parser() with
argv[0] set to "nviz".
> > I don't remember running into this in 5.3,
>
> It was a problem in 5.3, but without the SQL queries it only affects the
> d.text modules AFAIK. Fixed in CVS. Both the 5.3 and 5.7 changes make
> the shell command preview un-cut&paste-able for things with spaces in
> them, but this never worked before either.. some fancy formatting before
> printing the text string could probably move & replace the {}s to "s if
> someone was keen to try.
set string {}
foreach word $cmd {
regsub -all -- {'} $word {'\''} newword
append string {'} $newword {' }
}
--
Glynn Clements <glynn.clements@virgin.net>
|
|
Wed, Aug 4 2004
06:42:03
|
|
Mail sent by michael.barton@asu.edu
|
|
Return-Path |
<Michael.Barton@asu.edu>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Tue, 03 Aug 2004 21:41:07 -0700
|
From |
Michael Barton <michael.barton@asu.edu>
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
In-reply-to |
<20040804130608.28360ccf.hamish_nospam@yahoo.com>
|
To |
Hamish <hamish_nospam@yahoo.com>
|
Cc |
grass-bugs@intevation.de, grass5@grass.itc.it
|
Message-id |
<BD35B6F3.BB8%michael.barton@asu.edu>
|
MIME-version |
1.0
|
Content-type |
text/plain; charset=US-ASCII
|
Content-transfer-encoding |
7bit
|
User-Agent |
Microsoft-Entourage/11.0.0.040405
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
> From: Hamish <hamish_nospam@yahoo.com>
> Date: Wed, 04 Aug 2004 13:06:08 +1200
> To: Michael Barton <michael.barton@asu.edu>
> Cc: <grass-bugs@intevation.de>, <grass5@grass.itc.it>
> Subject: Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string
> reading ability in g.parser
>
> The error is still in grass51/gui/tcltkgrass/main/gui.tcl but that is
> in now unused code which should be ripped out???
>
Hamish,
This is an enormous improvement in usability across all of GRASS in one fell
swoop. Thanks much.
If you know where this is in gui.tcl and want to remove it, go ahead (or
perhaps comment it out until it can be tested). Or if you tell me where it
is, I can do it. I assume you mean in gui.tcl for 5.7.
Michael
|
|
Wed, Aug 4 2004
10:40:15
|
|
Mail sent by paul-grass@stjohnspoint.co.uk
|
|
Return-Path |
<paul-grass@stjohnspoint.co.uk>
|
Delivered-To |
grass-bugs@lists.intevation.de
|
Date |
Wed, 4 Aug 2004 09:40:12 +0100 (BST)
|
From |
Paul Kelly <paul-grass@stjohnspoint.co.uk>
|
To |
Glynn Clements <glynn.clements@virgin.net>
|
Cc |
Michael Barton <michael.barton@asu.edu>, Hamish <hamish_nospam@yahoo.com>, grass-bugs@intevation.de, grass5@grass.itc.it
|
Subject |
Re: [GRASS5] [bug #2488] (grass) GRASS 5.7 WISH - improve string reading ability in g.parser
|
In-Reply-To |
<16656.16192.991231.825726@cerise.nosuchdomain.co.uk>
|
Message-ID |
<Pine.LNX.4.60.0408040936390.12442@agrippa.ukshells.co.uk>
|
References |
<20040803194327.022ae4e7.hamish_nospam@yahoo.com> <BD350103.2593%michael.barton@asu.edu> <16656.16192.991231.825726@cerise.nosuchdomain.co.uk>
|
MIME-Version |
1.0
|
Content-Type |
TEXT/PLAIN; charset=US-ASCII; format=flowed
|
X-Spam-Status |
No, hits=-4.9 tagged_above=-999.0 required=3.0 tests=BAYES_00
|
X-Spam-Level |
|
On Wed, 4 Aug 2004, Glynn Clements wrote:
>> I don't remember running into this in 5.3, but the GUI is very different in
>> 5.3; G.PARSER() works but doesn't autogenerate the dialog boxes. They are
>> each coded individually.
>
> The 5.0/5.3 problems are essentially the same bugs, but in different
> code. 5.0/5.3 has tcltkgrass, which is a self-contained Tcl/Tk program
> which works by executing GRASS commands.
>
> In 5.7, the problems are in G_gui(), which is called by G_parser(),
> which is used by most commands to parse the command line. In 5.0/5.3,
> if a command was run without arguments, G_parser() would ask the user
> for the infomation via the terminal. In 5.7, it generates and runs a
> Tcl/Tk program which displays a dialog, then re-executes the command
> using the data from the dialog fields as arguments.
I would just add that this happens unless the environment variable
GRASS_UI_TERM is set (to any value). If this is true then the old parser
behaviour (terminal-based) happens. Also the 5.7 tcltkgrass doesn't
attempt to unset this variable if it is already set so if it is set, then
the autogenerated dialog boxes don't appear and the GUI doesn't work. A
minor issue.
Paul
|
|
Fri, Oct 22 2004
07:29:19
|
|
Subject changed to 5.7: nviz won't start from the GUI by hbowman
|
|
Fri, Oct 22 2004
07:30:24
|
|
Comments added by hbowman
|
|
tcl whitespace problem is resolved, nviz --ui problem remains.
renaminbg bug.
|
|
Mon, Feb 28 2005
23:08:17
|
|
Status changed to resolved by hbowman
|
|