[GRASS-dev] gis.m in wingrass: using where clause in d.vect causes error :can't read "_data(.gronsole.gronsole, 9, donecmd)": no such element in array

[Michael Barton]

Would double quotes work better? While I understand the issue, I don't know
what to do about it as I'm not familiar with sh on Windows.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
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


> From: Moritz Lennert <mlennert at club.worldonline.be>
> Date: Mon, 23 Oct 2006 20:59:08 +0200 (CEST)
> To: Glynn Clements <glynn at gclements.plus.com>
> Cc: Huidae Cho <grass4u at gmail.com>, <michael.barton at asu.edu>,
> <grass-dev at grass.itc.it>
> Subject: Re: [GRASS-dev] gis.m in wingrass: using where clause in d.vect
> causes error :can't read "_data(.gronsole.gronsole, 9, donecmd)": no such
> element in array
> 
> On Tue, October 10, 2006 05:22, Glynn Clements wrote:
>> 
>> Moritz Lennert wrote:
>> 
>>>>> Huidae or Glynn, any ideas on this ?
>>>> 
>>>> # Actually run the program
>>>> if { $mingw == "1" } {
>>>> # shell scripts require sh.exe.
>>>> set cmd [concat | sh -c '$cmd']
>>>> } else {
>>>> set cmd [concat | $cmd 2>@ stdout]
>>>> }
>>>> 
>>>> If you want to use "sh -c ...", you have to escape any shell
>>>> metacharacters, otherwise commands which happen to contain shell
>>>> metacharacters (e.g. "<" or ">" in a SQL "WHERE" clause) won't work.
>>>> 
>>>> I've already explained this in the thread discussing these changes.
>>> 
>>> Found
>>> http://grass.itc.it/pipermail/grass5/2006-September/025834.html
>>> 
>>> where you say
>>> 
>>>  "The simplest solution to the issue of
>>>  metacharacters is to replace any occurrences of the single quote
>>>  character in arguments with "'\''" (quote, backslash, quote, quote)
>>>  and surround each argument with single quotes.
>>> 
>>>  Even then, there might be issues due to the shell messing with the
>>>  environment, signal handling, process groups etc (as well as possible
>>>  Unix-compatibility "features"). Shells are very complex programs."
>>> 
>>> Not sure that I understand exactly what needs to be done and where.
>> 
>> In the above Tcl code, $cmd is a Tcl list (a string using a specific
>> syntax which ensures that element boundaries are preserved even when
>> elements contain spaces etc).
>> 
>> Using that string as an argument to "sh -c ..." will only work
>> correctly if the format of the string is such that the shell will
>> parse it into the same list of strings that Tcl would. In practice,
>> this will only happen if none of the elements contain any characters
>> which are significant to either Tcl or the shell (which includes
>> spaces, as they are normally treated as element separators).
>> 
>> IOW, "sh -c '$cmd'" will only work for commands where none of the
>> arguments contain either Tcl or shell metacharacters. If you want to
>> invoke $cmd via "sh -c ...", you have to take the list apart and
>> construct a command line using shell syntax.
>> 
>> E.g. (untested):
>> 
>> set shcmd ""
>> foreach arg $cmd {
>> set arg2 [regsub -all {'} $arg {'\''}]
>> if {$shcmd == ""} {
>> set shcmd "'$arg2'"
>> } else {
>> set shcmd "$shcmd '$arg2'"
>> }
>> }
>> set cmd [concat | sh -c $shcmd]
> 
> Finally gotten around to trying this. After adding simple quotes to the
> last line:
> 
>       set cmd [concat | sh -c '$shcmd']
> 
> I don't get the error anymore, but it still doesn't work as it should:
> 
> comcod=21004 works
> 
> but comcod=21004 and comcod=21005
> 
> only show comcod=21004, not 21005
> 
> and comcod>21004 doesn't show anything, but doesn't produce an error message.
> 
> 
>> 
>> However, for various reasons, it would be better if we could find a
>> way avoid using "sh -c ..." altogether. The problem there is that you
>> can't directly execute shell scripts on Windows.
> 
> agreed, but have we found a way for doing this, yet, at least theoretically ?
> 
> Moritz
> 
>