[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

GRASS GIS GRASS GIS developer
1

Using a where clause in vector display in gis.m causes the following error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"
     (procedure "Gronsole::done_command" line 3)
     invoked from within
"Gronsole::done_command $path $ci"
     (procedure "Gronsole::execout" line 26)
     invoked from within
"Gronsole::execout $path $cmd $ci Gronsole::execwait"
     (procedure "Gronsole::run_wait" line 6)
     invoked from within
"Gronsole::run_wait .gronsole.gronsole {d.vect map=communes@PERMANENT color=0:0:0 lcolor=0:0:0 fcolor=170:170:170 display=shape type=point,line,boundar..."
     ("eval" body line 1)
     invoked from within
"eval Gronsole::$cmd .gronsole.gronsole $args"
     (procedure ".gronsole.gronsole" line 1)
     invoked from within
"$gronsole run_wait $cmd gism"
     (procedure "run_panel" line 4)
     invoked from within
"run_panel $cmd"
     (procedure "GmCommonLayer::display_commands" line 28)
     invoked from within
"GmCommonLayer::display_commands $namespace $id [list $cmd]"
     (procedure "GmCommonLayer::display_command" line 2)
     invoked from within
"GmCommonLayer::display_command [namespace current] $id $cmd"
     (procedure "GmVector::display" line 108)
     invoked from within
"GmVector::display $node $mod"
     ("vector" arm line 2)
     invoked from within
"switch $type {
         group {
             GmGroup::display $node $mod
    }
    raster {
      GmRaster::display $node $mod
    }
    labels {
      GmLabels::disp..."
     (procedure "GmTree::display_node" line 7)
     invoked from within
"GmTree::display_node $n $mod"
     (procedure "GmGroup::display" line 22)
     invoked from within
"GmGroup::display "root" $mod"
     (procedure "MapCanvas::runprograms" line 63)
     invoked from within
"MapCanvas::runprograms $mon [expr {$mymodified != 0}]"
     (procedure "MapCanvas::drawmap" line 38)
     invoked from within
"MapCanvas::drawmap $mon"
     (procedure "MapCanvas::display_server" line 9)
     invoked from within
"MapCanvas::display_server"
     ("after" script)

Moritz

2

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake. I just made the same
mistake trying to recreate your error.

(spearfish dataset, "fields" vector map, query: "cat > 30")

Put the query in the "use SQL query" box not the "query cat values" and
it performs the query & display correctly.

If you put "30" in the "query cat values" box it just draws area 30.

If you put "30,54" in the "query cat values" box it just draws areas 30
and 54.

If you put "30-54" in the "query cat values" box it just draws areas 30
through 54.

If you put "30-54" in the "query cat values" box it just draws areas 30
through 54.

If you put "30-54,63" in the "query cat values" box it just draws areas
30 through 54 and area 63.

I think the ">" is getting treated as a redirect. With other non int
range stuff in that line G_parser() gives an understandable error.

better wording and/or input sanity checks needed in gis.m..
(or note-to-self for future WxPython rewrites).

Hamish

3

On Sun, October 8, 2006 04:59, Hamish wrote:

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive that this
is not the problem here. I entered the query in the where box, not the cat
box.

But I'll make sure tomorrow.

Moritz

4

On Sun, October 8, 2006 10:30, Moritz Lennert wrote:

On Sun, October 8, 2006 04:59, Hamish wrote:

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive that this
is not the problem here. I entered the query in the where box, not the cat
box.

But I'll make sure tomorrow.

Actually I just managed to test (Qemu over NX, quite an experience :wink: ),
and I can confirm that the problem is with the sql query box. So it is not
the same problem as the one described by Hamish.

Moritz

5

Something along this line popped up in a Mac installation. I think it was a
colleague of William Kyngesburye, so I'm copying him here. In that case
there was something missing in the installation that finally turned out to
be the problem.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Sun, 8 Oct 2006 10:30:22 +0200 (CEST)
To: Hamish <hamish_nospam@yahoo.com>, <michael.barton@asu.edu>
Cc: <grass-dev@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 Sun, October 8, 2006 04:59, Hamish wrote:

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive that this
is not the problem here. I entered the query in the where box, not the cat
box.

But I'll make sure tomorrow.

Moritz

6

I was holding off on replying to this, waiting for a windows reply. And, this issue was brought up mid-Sept also, I guess a solution wasn't found then.

The Mac problem had to do with using TclTk Aqua vs. X11. For Aqua the osxaqua=1 env must be set, or you get this error. Maybe if you look at what setting osxaqua makes GRASS do differently with the GUI? There are a couple settings in init.sh dependent on osxaqua, I never looked to see if it's used elsewhere.

This is the Mac bug:

http://intevation.de/rt/webrt?serial_num=5096&display=History

On Oct 9, 2006, at 3:38 AM, Michael Barton wrote:

Something along this line popped up in a Mac installation. I think it was a
colleague of William Kyngesburye, so I'm copying him here. In that case
there was something missing in the installation that finally turned out to
be the problem.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Sun, 8 Oct 2006 10:30:22 +0200 (CEST)
To: Hamish <hamish_nospam@yahoo.com>, <michael.barton@asu.edu>
Cc: <grass-dev@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 Sun, October 8, 2006 04:59, Hamish wrote:

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive that this
is not the problem here. I entered the query in the where box, not the cat
box.

But I'll make sure tomorrow.

Moritz

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that the past isn't a fiction designed to account for the discrepancy between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe

7

Here is what happens for setting the osx aqua variable.

Mac Aqua version of TclTk is used instead of x11 version

The GUI startup script, gis.m is launched with...

    "$GISBASE/scripts/gis.m" | sh &
    
Instead of with...

    "$GISBASE/scripts/gis.m" &

The variable execom is set to "spawn"; otherwise it is "execute"

I think this was used for awhile in the menu system, but can't find any use
for this now. If true, it needs to be deleted.

I'm adding Lorenzo to the CC list. He developed the aqua variable and has
worked the most with this version of TclTk.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: William Kyngesburye <woklist@kyngchaos.com>
Reply-To: William Kyngesburye <kyngchaos@kyngchaos.com>
Date: Mon, 9 Oct 2006 07:56:22 +0900
To: Michael Barton <michael.barton@asu.edu>
Cc: Moritz Lennert <mlennert@club.worldonline.be>, Hamish
<hamish_nospam@yahoo.com>, <grass-dev@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

I was holding off on replying to this, waiting for a windows reply.
And, this issue was brought up mid-Sept also, I guess a solution
wasn't found then.

The Mac problem had to do with using TclTk Aqua vs. X11. For Aqua
the osxaqua=1 env must be set, or you get this error. Maybe if you
look at what setting osxaqua makes GRASS do differently with the
GUI? There are a couple settings in init.sh dependent on osxaqua, I
never looked to see if it's used elsewhere.

This is the Mac bug:

http://intevation.de/rt/webrt?serial_num=5096&display=History

On Oct 9, 2006, at 3:38 AM, Michael Barton wrote:

Something along this line popped up in a Mac installation. I think
it was a
colleague of William Kyngesburye, so I'm copying him here. In that
case
there was something missing in the installation that finally turned
out to
be the problem.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Sun, 8 Oct 2006 10:30:22 +0200 (CEST)
To: Hamish <hamish_nospam@yahoo.com>, <michael.barton@asu.edu>
Cc: <grass-dev@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 Sun, October 8, 2006 04:59, Hamish wrote:

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the
following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive
that this
is not the problem here. I entered the query in the where box, not
the cat
box.

But I'll make sure tomorrow.

Moritz

-----
William Kyngesburye <kyngchaos@kyngchaos.com>
http://www.kyngchaos.com/

"This is a question about the past, is it? ... How can I tell that
the past isn't a fiction designed to account for the discrepancy
between my immediate physical sensations and my state of mind?"

- The Ruler of the Universe

8

Moritz Lennert wrote:

On Sun, October 8, 2006 10:30, Moritz Lennert wrote:

On Sun, October 8, 2006 04:59, Hamish wrote:

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive that this
is not the problem here. I entered the query in the where box, not the cat
box.

But I'll make sure tomorrow.

Actually I just managed to test (Qemu over NX, quite an experience :wink: ),
and I can confirm that the problem is with the sql query box. So it is not
the same problem as the one described by Hamish.

Huidae or Glynn, any ideas on this ?

Moritz

9

Moritz Lennert wrote:

>>>> Using a where clause in vector display in gis.m causes the following
>>>> error under WinGRASS. Any suggestions ?
>>>> (WinGRASS version 2006-09-17)
>>>>
>>>> can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
>>>> array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
>>>> element in array
>>>> while executing
>>>> "set donecmd $_data($path,$ci,donecmd)"
>>>
>>> also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
>>> query in the "query cat values" box by mistake.
>> I am not near a windows box right now, but I am quite positive that this
>> is not the problem here. I entered the query in the where box, not the cat
>> box.
>>
>> But I'll make sure tomorrow.
>
> Actually I just managed to test (Qemu over NX, quite an experience :wink: ),
> and I can confirm that the problem is with the sql query box. So it is not
> the same problem as the one described by Hamish.

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.

--
Glynn Clements <glynn@gclements.plus.com>

10

Glynn Clements wrote:

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive that this
is not the problem here. I entered the query in the where box, not the cat
box.

But I'll make sure tomorrow.

Actually I just managed to test (Qemu over NX, quite an experience :wink: ),
and I can confirm that the problem is with the sql query box. So it is not
the same problem as the one described by Hamish.

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.

Moritz

11

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]

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.

--
Glynn Clements <glynn@gclements.plus.com>

12

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

13

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@club.worldonline.be>
Date: Mon, 23 Oct 2006 20:59:08 +0200 (CEST)
To: Glynn Clements <glynn@gclements.plus.com>
Cc: Huidae Cho <grass4u@gmail.com>, <michael.barton@asu.edu>,
<grass-dev@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

14

Moritz Lennert wrote:

> 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']

That's wrong. There definitely shouldn't be quotes around the command
as a whole. If it doesn't work without them, that suggests that
something else is messing with the command.

> 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 ?

Execute commands via a launcher program.

The launcher would first locate the executable named by its first
argument. If it's an absolute path, use it directly, otherwise search
the execution path.

If it finds a match with a known executable suffix (.exe, .bat, .cmd
etc), execute that.

If it finds a match with no suffix, open the file, and check whether
the first two bytes are "#!". If they are, read the interpreter (e.g.
"/bin/sh") from the script, look up the corresponding program in a
table of known interpreters, and run the interpreter with the script
filename as the first argument, followed by the command's arguments.

This is essentially what the Unix kernel does when you call execve(),
and what Unix emulation layers such as Cygwin or MSys' bash do. Using
"sh -c ..." with MSys is using the execve() emulation in MSys' bash,
but bash is a rather heavy-weight solution. A launcher that just
identifies scripts and does nothing else would be preferable.

--
Glynn Clements <glynn@gclements.plus.com>

15

On Tue, October 24, 2006 02:49, Glynn Clements wrote:

Moritz Lennert wrote:

> 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']

That's wrong. There definitely shouldn't be quotes around the command
as a whole. If it doesn't work without them, that suggests that
something else is messing with the command.

When I don't put in these quotes, and I try to simply display a map, I get:

couldn't open "1708.1.ppm": no such file or directory
couldn't open "1708.1.ppm": no such file or directory
    while executing
"image create photo mapimg.$mon -file "$outfile($mon)""
    (procedure "MapCanvas::composite" line 21)
    invoked from within
"MapCanvas::composite $mon"
    (procedure "MapCanvas::drawmap" line 40)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::display_server" line 9)
    invoked from within
"MapCanvas::display_server"
    ("after" script)

When I put them in, the map displays as it should.

> 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 ?

Execute commands via a launcher program.

What would be the best choice of language for such a program.

Moritz

16

This error suggests that the d.vect command is failing to create an image.

Michael
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University

phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

From: Moritz Lennert <mlennert@club.worldonline.be>
Date: Tue, 24 Oct 2006 10:39:04 +0200 (CEST)
To: Glynn Clements <glynn@gclements.plus.com>
Cc: Huidae Cho <grass4u@gmail.com>, <michael.barton@asu.edu>,
<grass-dev@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 24, 2006 02:49, Glynn Clements wrote:

Moritz Lennert wrote:

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']

That's wrong. There definitely shouldn't be quotes around the command
as a whole. If it doesn't work without them, that suggests that
something else is messing with the command.

When I don't put in these quotes, and I try to simply display a map, I get:

couldn't open "1708.1.ppm": no such file or directory
couldn't open "1708.1.ppm": no such file or directory
    while executing
"image create photo mapimg.$mon -file "$outfile($mon)""
    (procedure "MapCanvas::composite" line 21)
    invoked from within
"MapCanvas::composite $mon"
    (procedure "MapCanvas::drawmap" line 40)
    invoked from within
"MapCanvas::drawmap $mon"
    (procedure "MapCanvas::display_server" line 9)
    invoked from within
"MapCanvas::display_server"
    ("after" script)

When I put them in, the map displays as it should.

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 ?

Execute commands via a launcher program.

What would be the best choice of language for such a program.

Moritz

17

Moritz Lennert wrote:

>> > 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']
>
> That's wrong. There definitely shouldn't be quotes around the command
> as a whole. If it doesn't work without them, that suggests that
> something else is messing with the command.

When I don't put in these quotes, and I try to simply display a map, I get:

couldn't open "1708.1.ppm": no such file or directory
couldn't open "1708.1.ppm": no such file or directory

As Michael says, the command isn't creating an image. Doesn't the
gis.m log provide any clues?

>> > 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 ?
>
> Execute commands via a launcher program.

What would be the best choice of language for such a program.

C. The launcher needs to be a compiled executable, otherwise you run
into exactly the same problem (Windows doesn't understand "#!") when
running the launcher.

The alternative is to force scripts to have an extension (.sh for
shell scripts, .tcl for Tcl, etc). But then, you either need to type
the extension on Unix, or you have to ensure that scripts only have an
extension on Windows.

--
Glynn Clements <glynn@gclements.plus.com>

18

On Mon, 9 Oct 2006, Glynn Clements wrote:

Moritz Lennert wrote:

Using a where clause in vector display in gis.m causes the following
error under WinGRASS. Any suggestions ?
(WinGRASS version 2006-09-17)

can't read "_data(.gronsole.gronsole,9,donecmd)": no such element in
array can't read "_data(.gronsole.gronsole,9,donecmd)": no such
element in array
     while executing
"set donecmd $_data($path,$ci,donecmd)"

also seen on Linux, GRASS versions 6.3 and 6.2-rc1 IF you put the
query in the "query cat values" box by mistake.

I am not near a windows box right now, but I am quite positive that this
is not the problem here. I entered the query in the where box, not the cat
box.

But I'll make sure tomorrow.

Actually I just managed to test (Qemu over NX, quite an experience :wink: ),
and I can confirm that the problem is with the sql query box. So it is not
the same problem as the one described by Hamish.

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 got this working by changing the above (in gronsole.tcl) to:
         # Actually run the program
         if { $mingw == "1" } {
                 set cmd [concat | $cmd |& cat]
         } else {
                 set cmd [concat | $cmd 2>@ stdout]
         }

A few Tcl help-related webpages recommend using "|& cat" to merge stdout and stderr. Unfortunately that's using the cat command that was installed with Msys, ideally we should get it working without Msys but all it needs is a simple program that reads from stdin and copies to stdout? Then it could be a cross-platform solution and we could get rid of the Mingw checks - I like doing that :).

In a few places also needed to change
if {[info exists env(MSYSCON)]}
to
if {[info exists env(OS)] && $env(OS) == "Windows_NT"}
which is still ugly but at least not Msys-specific.

Will comment more on it later; just noting this to the list now as I have a million other things going on in my head and might forget (this solves the problem I reported with gis.m earlier today - it wasn't with gis.m at all (sorry) but with the auto-generated Tcl/Tk dialog boxes for modules).

Paul