[GRASS-dev] select issue with wingrass

GRASS GIS GRASS GIS developer
1

On Sat, November 10, 2007 17:37, Michael Barton wrote:

We tried installing twice the old way. Then when Isaac had him install the
other way, it worked. Isaac said that there were some files preceded by 2
dots (i.e., ..file) that *didn't* get copied the first times. He is
guessing
that there are some Unix files that don't get installed properly under XP
by
simply opening the zip file and dragging the content. It needs to be
completely unzipped.

Today, I suddenly have seen the problem appear and I don't really
understand where this comes from:

The only situation where I get the select window to work, is when I launch
grass via a shortcut to the grass63.bat and this shortcut is configured to
use c:\ as the working directory. Any other working directory (including
the default of the shortcut which is c:\grass\bin) gives me the empty
select window Javi as been seeing. The same when I click directly on
c:\grass\bin\grass63.bat. When I start grass in text mode and then launch
gis.m from the command line, it is exactly the same: I can only see the
maps in the select window if the current directory is c:\ when I launch
gis.m.

So it seems to be linked to gis.m. Have there been any changes recently
that might explain this ? I have never even worried about the working
directory before, except for testing whether setting %USERPROFILE% in the
shortcut properties works and it did at the time. Now it doesn't
anymore...

Javi and Michael, could you also test whether this corresponds to what is
happening in your case ?

Moritz

2

Moritz,

I'm glad that you've been able to verify the select issue and find out more
about how it happens.

There have been no changes to gis.m that might cause this as far as I know.
I made some changes to select.tcl several months back to fix the
multi-select option that had been broken by updates several months before
that. In the part that I changed, I replaced unix-based regexp statements
with pure TclTk list parsing. If anything, this should make the selection
tools work better with Windows. But this all was some time ago. If there
have been any changes by others that might cause this, I'm not aware of
them.

We've now encountered a couple of other items, even though select is
working, at least in some settings.

It appears that r.mapcalc is NOT working. We get an error with even the
simplest of mapcalc statements. Javi will send the error message tonight or
tomorrow, but it is a red herring IMHO, stating that it is missing an "=".
We have the same error if we run r.mapcalc via the TclTk interface
(r.mapcalculator) or run it from the console command line. Other commands
work find from the console command line. This is *critical*, of course, as
r.mapcalc is very important to GRASS analysis and map management.

Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
anything from the error message box or even make the box bigger so as to
show more of the error details. Is there a way to log this to send to you,
as it is quite long?

Interestingly, we are getting the *same* error produced by v.in.db when
running r.contour.

We did NOT get an error running r.to.vect, v.in.region, or v.random. So it
is not just something that happens anytime we try to create a vector. Maybe
this is helpful.

Thanks for taking the time to help troubleshoot this.

Michael

On 11/10/07 5:10 PM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

On Sat, November 10, 2007 17:37, Michael Barton wrote:

We tried installing twice the old way. Then when Isaac had him install the
other way, it worked. Isaac said that there were some files preceded by 2
dots (i.e., ..file) that *didn't* get copied the first times. He is
guessing
that there are some Unix files that don't get installed properly under XP
by
simply opening the zip file and dragging the content. It needs to be
completely unzipped.

Today, I suddenly have seen the problem appear and I don't really
understand where this comes from:

The only situation where I get the select window to work, is when I launch
grass via a shortcut to the grass63.bat and this shortcut is configured to
use c:\ as the working directory. Any other working directory (including
the default of the shortcut which is c:\grass\bin) gives me the empty
select window Javi as been seeing. The same when I click directly on
c:\grass\bin\grass63.bat. When I start grass in text mode and then launch
gis.m from the command line, it is exactly the same: I can only see the
maps in the select window if the current directory is c:\ when I launch
gis.m.

So it seems to be linked to gis.m. Have there been any changes recently
that might explain this ? I have never even worried about the working
directory before, except for testing whether setting %USERPROFILE% in the
shortcut properties works and it did at the time. Now it doesn't
anymore...

Javi and Michael, could you also test whether this corresponds to what is
happening in your case ?

Moritz

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

3

Michael Barton wrote:

Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
anything from the error message box or even make the box bigger so as to
show more of the error details. Is there a way to log this to send to you,
as it is quite long?

create a screenshot with Alt-PrintScreen then paste into a paint program?

Hamish

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

4

Michael Barton wrote:

It appears that r.mapcalc is NOT working. We get an error with even the
simplest of mapcalc statements. Javi will send the error message tonight or
tomorrow, but it is a red herring IMHO, stating that it is missing an "=".
We have the same error if we run r.mapcalc via the TclTk interface
(r.mapcalculator) or run it from the console command line. Other commands
work find from the console command line. This is *critical*, of course, as
r.mapcalc is very important to GRASS analysis and map management.

FWIW, the only r.mapcalc files which have changed in the last three
months are:

  Makefile
  map3.c
  r.mapcalc.html
  r3.mapcalc.html

The Makefile changes were part of the parallel build effort, and don't
change what is compiled or which switches are used. The map3.c changes
are just standardisation of messages, and only affect r3.mapcalc.

I presume that this is related to your local environment; otherwise, I
would expect to see other people reporting it.

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

5

On 11/12/07 1:26 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:

Michael Barton wrote:

Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
anything from the error message box or even make the box bigger so as to
show more of the error details. Is there a way to log this to send to you,
as it is quite long?

create a screenshot with Alt-PrintScreen then paste into a paint program?

We've done that, but it's not very helpful. It is a very long error message
and Windows only presents a small, non-resizable window.

Michael

Hamish

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

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

6

On 11/12/07 4:14 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

It appears that r.mapcalc is NOT working. We get an error with even the
simplest of mapcalc statements. Javi will send the error message tonight or
tomorrow, but it is a red herring IMHO, stating that it is missing an "=".
We have the same error if we run r.mapcalc via the TclTk interface
(r.mapcalculator) or run it from the console command line. Other commands
work find from the console command line. This is *critical*, of course, as
r.mapcalc is very important to GRASS analysis and map management.

FWIW, the only r.mapcalc files which have changed in the last three
months are:

Makefile
map3.c
r.mapcalc.html
r3.mapcalc.html

The Makefile changes were part of the parallel build effort, and don't
change what is compiled or which switches are used. The map3.c changes
are just standardisation of messages, and only affect r3.mapcalc.

I presume that this is related to your local environment; otherwise, I
would expect to see other people reporting it.

Unfortunately, not many people testing new WinGRASS alpha builds yet I fear.

I did some more tests this morning, this time on my Mac and may have
discovered the cause of the error.

For the current WinGRASS binary, it is necessary to use the command console
for command-line use of GRASS.

We received an error with the following simple mapcalc statements

r.mapcalc 'frict=1'
r.mapcalc 'test=pendiente*2'

It turns out that you cannot use single quotes in this context. You need to
use regular quotes. So the way to specify the same mapcalc statements from
the GUI command console is...

r.mapcalc "frict=1"
r.mapcalc "test=pendiente*2"

I thought we had tried double quotes too, but maybe we didn't. I'll wait for
Javi to check email and test. The worrisome thing is that we initially used
the GUI map calculator from the menu and got an error. I tried it this
morning on my Mac and did not get an error.

Michael

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

7

We received an error with the following simple mapcalc statements

r.mapcalc 'frict=1'
r.mapcalc 'test=pendiente*2'

It turns out that you cannot use single quotes in this context. You need to
use regular quotes. So the way to specify the same mapcalc statements from
the GUI command console is...

r.mapcalc "frict=1"
r.mapcalc "test=pendiente*2"

I can confirm this behaviour using Windows' cmd.exe shell. It does not
seem to be able to handle single quotes correctly. But then again,
cmd.exe is sth. very different from your regular unixish shell.
If I run MSYS' sh.exe in the Windows console, things tend to work fine
for me.

Benjamin

--
Benjamin Ducke, M.A.
Archäoinformatik
(Archaeoinformation Science)
Institut für Ur- und Frühgeschichte
(Inst. of Prehistoric and Historic Archaeology)
Christian-Albrechts-Universität zu Kiel
Johanna-Mestorf-Straße 2-6
D 24098 Kiel
Germany

Tel.: ++49 (0)431 880-3378 / -3379
Fax : ++49 (0)431 880-7300
www.uni-kiel.de/ufg

8

On Mon, 12 Nov 2007, Benjamin Ducke wrote:

We received an error with the following simple mapcalc statements

r.mapcalc 'frict=1'
r.mapcalc 'test=pendiente*2'

It turns out that you cannot use single quotes in this context. You need to
use regular quotes. So the way to specify the same mapcalc statements from
the GUI command console is...

r.mapcalc "frict=1"
r.mapcalc "test=pendiente*2"

I can confirm this behaviour using Windows' cmd.exe shell. It does not
seem to be able to handle single quotes correctly. But then again,
cmd.exe is sth. very different from your regular unixish shell.

Yes it's nothing new. You need to know a bit more about Windows than just how to point and click to be able to get the most out of GRASS I suppose---we're moving away from that obviously - but it still helps.

ISTR around this time last year when we were fixing a lot of tedious little things to improve Windows compatibility, having to change commands run with system() or similar from within C programs to use double instead of single quotes was quite a common problem. Hopefully most occurences within C programs have been caught now but perhaps there are still some in gis.m?

Paul

9

Paul Kelly wrote:

ISTR around this time last year when we were fixing a lot of tedious
little things to improve Windows compatibility, having to change commands
run with system() or similar from within C programs to use double instead
of single quotes was quite a common problem. Hopefully most occurences
within C programs have been caught now but perhaps there are still some in
gis.m?

gis.m shouldn't be using a shell to execute commands, so shell syntax
shouldn't come into it.

BTW, if anyone wants to take another stab at eliminating shell usage
in C modules, I've added G_vspawn_ex() and SF_ARGVEC since the last
attempt. This should solve the problems with passing variable argument
lists. See the thread "testing native winGRASS" from March for context
(no URL as the web site seems to be down right now).

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

10

On Sun, November 11, 2007 01:10, Moritz Lennert wrote:

On Sat, November 10, 2007 17:37, Michael Barton wrote:

We tried installing twice the old way. Then when Isaac had him install
the
other way, it worked. Isaac said that there were some files preceded by
2
dots (i.e., ..file) that *didn't* get copied the first times. He is
guessing
that there are some Unix files that don't get installed properly under
XP
by
simply opening the zip file and dragging the content. It needs to be
completely unzipped.

Today, I suddenly have seen the problem appear and I don't really
understand where this comes from:

I have advanced a little bit trying to debug this, although I have no idea
why this has suddenly appeared and wasn't there all the time, and I'm,
therefore, not sure that this is really the origin of the problem.

select.tcl uses both the GISDBASE and MAPSET env variables. However,
neither seem to be defined in wingrass (Init.sh sets them, but Init.bat
doesn't). So I tried the following:

- enter GRASS
- set GISDBASE=c:\GRASSDATA
- run in tclsh
% set location_path "$env(GISDBASE)/$env(LOCATION_NAME)/'
% set dir "user1"
% set element "vector"
% set path "$location_path/$dir/$element/
% glob -nocomplain $path/*

This returns nothing.
When I set GISDBASE=c:/GRASSDATA (forward slash), it returns the list of
complete paths to all elements.

However, when I set GISDBASE and MAPSET at the command line before
launching gis.m this does not solve the problem of nothing being listed in
the select windows...

The only way to get a list, still is to start gis.m when the working
directory is c:\.

Any hints welcome.

Moritz

11

Moritz Lennert wrote:

I have advanced a little bit trying to debug this, although I have no idea
why this has suddenly appeared and wasn't there all the time, and I'm,
therefore, not sure that this is really the origin of the problem.

select.tcl uses both the GISDBASE and MAPSET env variables.

They aren't supposed to be environment variables.

I'm surprised that select.tcl has worked so far. It should be using
g.gisenv to get those values.

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

12

Glynn Clements wrote:

> I have advanced a little bit trying to debug this, although I have no idea
> why this has suddenly appeared and wasn't there all the time, and I'm,
> therefore, not sure that this is really the origin of the problem.
>
> select.tcl uses both the GISDBASE and MAPSET env variables.

They aren't supposed to be environment variables.

I'm surprised that select.tcl has worked so far. It should be using
g.gisenv to get those values.

Ah; the reason it's been working so far is that both lib/gis/gui.tcl
and gui/tcltk/gis.m/gm.tcl set them, e.g.:

if {[catch {set env(GISDBASE) [exec g.gisenv get=GISDBASE]} error]} {

Any other code which uses select.tcl will need to do likewise.

Use of env() is less than ideal (there's already enough confusion
between GRASS variables and environment variables), but using separate
variables would require changing a lot of "global" statements.

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

13

If this is set in gui.tcl (the first thing run by the GRASS TclTk gui),
won't it then be available to all other gui modules?

That is, why can't select.tcl access GISBASE if env(GISBASE) is set in
gui.tcl?

Michael

On 11/18/07 8:42 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Glynn Clements wrote:

I have advanced a little bit trying to debug this, although I have no idea
why this has suddenly appeared and wasn't there all the time, and I'm,
therefore, not sure that this is really the origin of the problem.

select.tcl uses both the GISDBASE and MAPSET env variables.

They aren't supposed to be environment variables.

I'm surprised that select.tcl has worked so far. It should be using
g.gisenv to get those values.

Ah; the reason it's been working so far is that both lib/gis/gui.tcl
and gui/tcltk/gis.m/gm.tcl set them, e.g.:

if {[catch {set env(GISDBASE) [exec g.gisenv get=GISDBASE]} error]} {

Any other code which uses select.tcl will need to do likewise.

Use of env() is less than ideal (there's already enough confusion
between GRASS variables and environment variables), but using separate
variables would require changing a lot of "global" statements.

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

14

Michael Barton wrote:

>>> I have advanced a little bit trying to debug this, although I have no idea
>>> why this has suddenly appeared and wasn't there all the time, and I'm,
>>> therefore, not sure that this is really the origin of the problem.
>>>
>>> select.tcl uses both the GISDBASE and MAPSET env variables.
>>
>> They aren't supposed to be environment variables.
>>
>> I'm surprised that select.tcl has worked so far. It should be using
>> g.gisenv to get those values.
>
> Ah; the reason it's been working so far is that both lib/gis/gui.tcl
> and gui/tcltk/gis.m/gm.tcl set them, e.g.:
>
> if {[catch {set env(GISDBASE) [exec g.gisenv get=GISDBASE]} error]} {
>
> Any other code which uses select.tcl will need to do likewise.
>
> Use of env() is less than ideal (there's already enough confusion
> between GRASS variables and environment variables), but using separate
> variables would require changing a lot of "global" statements.

If this is set in gui.tcl (the first thing run by the GRASS TclTk gui),
won't it then be available to all other gui modules?

That is, why can't select.tcl access GISBASE if env(GISBASE) is set in
gui.tcl?

If the array element isn't set, or if "global env" is missing, you
would get an error from Tcl. That doesn't appear to be the case here.

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

15

Moritz Lennert wrote:

select.tcl uses both the GISDBASE and MAPSET env variables. However,
neither seem to be defined in wingrass (Init.sh sets them, but Init.bat
doesn't).

Init.sh sets them as shell variables; they aren't exported to the
environment.

So I tried the following:

- enter GRASS
- set GISDBASE=c:\GRASSDATA
- run in tclsh
% set location_path "$env(GISDBASE)/$env(LOCATION_NAME)/'
% set dir "user1"
% set element "vector"
% set path "$location_path/$dir/$element/
% glob -nocomplain $path/*

This returns nothing.
When I set GISDBASE=c:/GRASSDATA (forward slash), it returns the list of
complete paths to all elements.

[I missed this part before.]

That makes sense. Tcl uses forward slash internally on all platforms.
It suspect that it requires the use of "file normalize ..." on
Windows.

However, when I set GISDBASE and MAPSET at the command line before
launching gis.m this does not solve the problem of nothing being listed in
the select windows...

Yep; the startup code sets env(GISDBASE) etc via g.gisenv, which will
override any external settings (which shouldn't be there anyhow).

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

16

On 11/18/07 10:27 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

If this is set in gui.tcl (the first thing run by the GRASS TclTk gui),
won't it then be available to all other gui modules?

That is, why can't select.tcl access GISBASE if env(GISBASE) is set in
gui.tcl?

If the array element isn't set, or if "global env" is missing, you
would get an error from Tcl. That doesn't appear to be the case here.

The procedure in select.tcl DOES have global env...

proc GSelect_::create { element args } {
    # main procedure for creating and managing selection window, which a
tree
    # within a scrolling window.

    global env id

...However, gui.tcl sets env(GISDBASE) etc outside of any procedure (i.e.,
runs these before any procedure). But there is no global env statement.
Maybe this is needed for Windows?

Michael

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

17

Glynn Clements wrote:

Moritz Lennert wrote:

select.tcl uses both the GISDBASE and MAPSET env variables. However,
neither seem to be defined in wingrass (Init.sh sets them, but Init.bat
doesn't).

Init.sh sets them as shell variables; they aren't exported to the
environment.

So I tried the following:

- enter GRASS
- set GISDBASE=c:\GRASSDATA
- run in tclsh
% set location_path "$env(GISDBASE)/$env(LOCATION_NAME)/'
% set dir "user1"
% set element "vector"
% set path "$location_path/$dir/$element/
% glob -nocomplain $path/*

This returns nothing.
When I set GISDBASE=c:/GRASSDATA (forward slash), it returns the list of
complete paths to all elements.

[I missed this part before.]

That makes sense. Tcl uses forward slash internally on all platforms. It suspect that it requires the use of "file normalize ..." on
Windows.

I can confirm that this seems to be the problem: I had a .grassrc6 file with c:\grassdata in it. When I change this to c:/grassdata, the select window works from any working dir. By default (i.e. when there is no .grassrc6), grass writes the new file in the correct format (c:/grassdata). Don't know how I ended up with c:\grassdata...maybe I wrote it manually.

Michael and Javi can you confirm ?

Glynn Clements wrote:
> Ah; the reason it's been working so far is that both lib/gis/gui.tcl
> and gui/tcltk/gis.m/gm.tcl set them, e.g.:
>
> if {[catch {set env(GISDBASE) [exec g.gisenv get=GISDBASE]} error]} {
>
> Any other code which uses select.tcl will need to do likewise.
>
> Use of env() is less than ideal (there's already enough confusion
> between GRASS variables and environment variables), but using separate
> variables would require changing a lot of "global" statements.

Changing above line to

if {[catch {set env(GISDBASE) [exec g.dirseps -g [exec g.gisenv get=GISDBASE]]} error]} {

in lib/gis/gui.tcl seems to work for me. Can I commit ?

Should I also change this in gui/tcltk/gis.m/gm.tcl ?

Moritz

18

Michael Barton wrote:

>> If this is set in gui.tcl (the first thing run by the GRASS TclTk gui),
>> won't it then be available to all other gui modules?
>>
>> That is, why can't select.tcl access GISBASE if env(GISBASE) is set in
>> gui.tcl?
>
> If the array element isn't set, or if "global env" is missing, you
> would get an error from Tcl. That doesn't appear to be the case here.

The procedure in select.tcl DOES have global env...

proc GSelect_::create { element args } {
    # main procedure for creating and managing selection window, which a
tree
    # within a scrolling window.

    global env id

...However, gui.tcl sets env(GISDBASE) etc outside of any procedure (i.e.,
runs these before any procedure). But there is no global env statement.
Maybe this is needed for Windows?

No, it's reading the variable okay, it just can't use the value.

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

19

Michael Barton wrote:

On 11/12/07 4:14 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

It appears that r.mapcalc is NOT working. We get an error with even the
simplest of mapcalc statements. Javi will send the error message tonight or
tomorrow, but it is a red herring IMHO, stating that it is missing an "=".
We have the same error if we run r.mapcalc via the TclTk interface
(r.mapcalculator) or run it from the console command line. Other commands
work find from the console command line. This is *critical*, of course, as
r.mapcalc is very important to GRASS analysis and map management.

FWIW, the only r.mapcalc files which have changed in the last three
months are:

Makefile
map3.c
r.mapcalc.html
r3.mapcalc.html

The Makefile changes were part of the parallel build effort, and don't
change what is compiled or which switches are used. The map3.c changes
are just standardisation of messages, and only affect r3.mapcalc.

I presume that this is related to your local environment; otherwise, I
would expect to see other people reporting it.

Unfortunately, not many people testing new WinGRASS alpha builds yet I fear.

I did some more tests this morning, this time on my Mac and may have
discovered the cause of the error.

For the current WinGRASS binary, it is necessary to use the command console
for command-line use of GRASS.

We received an error with the following simple mapcalc statements

r.mapcalc 'frict=1'
r.mapcalc 'test=pendiente*2'

It turns out that you cannot use single quotes in this context. You need to
use regular quotes. So the way to specify the same mapcalc statements from
the GUI command console is...

r.mapcalc "frict=1"
r.mapcalc "test=pendiente*2"

I thought we had tried double quotes too, but maybe we didn't. I'll wait for
Javi to check email and test. The worrisome thing is that we initially used
the GUI map calculator from the menu and got an error. I tried it this
morning on my Mac and did not get an error.

In windows you don't need any quotation marks, so

r.mapcalc frict=1 also works, as does r.mapcalc x=frict/3.

The only issue might be special characters which you would have to escape somehow.

Moritz

20

Michael Barton wrote:

Also, we're still getting the dbf.exe error. Unfortunately, we cannot copy
anything from the error message box or even make the box bigger so as to
show more of the error details. Is there a way to log this to send to you,
as it is quite long?

Interestingly, we are getting the *same* error produced by v.in.db when
running r.contour.

Both v.in.db and r.contour work for me.

Could you give me exact command lines and the data you used ?

Moritz