[GRASS5] Re: [bug #2488] (grass) GRASS 5.7 WISH - improve string

[Michael Barton]

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.