[GRASS-dev] Re: winGRASS

GRASS GIS GRASS GIS developer
1

On Fri, December 15, 2006 23:50, Moritz Lennert wrote:

On Fri, December 15, 2006 18:01, Paul Kelly wrote:

On Fri, 15 Dec 2006, Moritz Lennert wrote:

Next step: make install

- doesn't install the grass63.bat file in bin
- when I copy grass63.bat to c:\grass\bin and modify it so that
set WINGISBASE=c:\grass\grass-6.3.cvs
I get error in startup script: "can't read "env(GISBASE)": no such
variable while executing "source $env(GISBASE)/etc/gtcltk/gmsg.tcl"
(file
"c:\grass\grass-6.3.cvs\etc\gis_set.tcl" line 29)

Possibly that something goes wrong in init.bat because the demolocation
directory doesn't get copied across during "make install"? I had been
using the .grassrc63 file in there as a temporary GISRC file so
g.dirseps
would work. Need to find a clean solution to this - all it needs is a
temporary file; it is fairly meaningless really. This ties in nicely
with
what Michael is looking at wrt a temporary GISRC file to make g.proj
run!

If you copy across "demolocation/.grassrc63" to the install directory
does
it work? If so, that confirms the problem and we need to look at a more
elegant solution with regard to the temporary GISRC files.

Yes, this works. Now I can startup grass without msys !

Now, to go on:

- I had hoped that Radim's patch for dbmi_client
(http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might
solve the issue I've had with the db protocol errors, but apparently this
is not the case. When I push the 'show the attribute columns' in a vector
panel, I still get

*******
Displaying column types/names for database connection of layer 1:
dbmi: Protocol error

Cannot open table <streams>
********

and a 'v.db.select' on the same map gives me:

********
'vector/streams' was found in more mapsets (also found in user1).
dbmi: Protocol error

Cannot open select cursor
*********

Radim, as you have been working on this these days, do you have an idea
what might be wrong ?

- I noticed that I can close the com.exe window and still continue using
grass. Is there any reason to keep this open ? If not, is there a way to
close it automatically ? Just a question of not multiplying unnecessary
windows.

- Help does not work. In individual command windows, the help button is
desactivated. In layer panels in the main GIS Manager window, when I push
the help button, I get:

child process exited abnormally
child process exited abnormally
    while executing
"exec -- g.manual d.vect >& NUL:"
    ("eval" body line 1)
    invoked from within
"eval [list exec -- $cmd] $args >& $devnull"
    (procedure "run" line 8)
    invoked from within
"run g.manual d.vect"
    ("uplevel" body line 1)
    invoked from within
"uplevel \#0 $cmd"
    (procedure "Button::_release" line 18)
    invoked from within
"Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e"
    (command bound to event)

2

On Mon, December 18, 2006 10:49, Moritz Lennert wrote:

On Fri, December 15, 2006 23:50, Moritz Lennert wrote:

On Fri, December 15, 2006 18:01, Paul Kelly wrote:

On Fri, 15 Dec 2006, Moritz Lennert wrote:

Next step: make install

- doesn't install the grass63.bat file in bin
- when I copy grass63.bat to c:\grass\bin and modify it so that
set WINGISBASE=c:\grass\grass-6.3.cvs
I get error in startup script: "can't read "env(GISBASE)": no such
variable while executing "source $env(GISBASE)/etc/gtcltk/gmsg.tcl"
(file
"c:\grass\grass-6.3.cvs\etc\gis_set.tcl" line 29)

Possibly that something goes wrong in init.bat because the demolocation
directory doesn't get copied across during "make install"? I had been
using the .grassrc63 file in there as a temporary GISRC file so
g.dirseps
would work. Need to find a clean solution to this - all it needs is a
temporary file; it is fairly meaningless really. This ties in nicely
with
what Michael is looking at wrt a temporary GISRC file to make g.proj
run!

If you copy across "demolocation/.grassrc63" to the install directory
does
it work? If so, that confirms the problem and we need to look at a more
elegant solution with regard to the temporary GISRC files.

Yes, this works. Now I can startup grass without msys !

Actually to be more precise, I had to copy the entire demolocation
directory with the PERMANENT mapset...

And some more issues:

- trying to create a new location from a georeferenced file or from an
EPSG code, I get:

couldn't execute "c:\grass\grass-6.3.cvs\etc\grass-xterm-wrapper": no such
file or directory
couldn't execute "c:\grass\grass-6.3.cvs\etc\grass-xterm-wrapper": no such
file or directory
    while executing
"exec -- $env(GISBASE)/etc/grass-xterm-wrapper -T g.proj -n g.proj -e
$env(GISBASE)/etc/grass-run.sh g.proj -c georef=$filepath
location=$fileLocation"
    invoked from within
".fileloc.def invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 24)
    invoked from within
"tk::ButtonUp .fileloc.def"
    (command bound to event)

I imagine that wingrass should'nt even call grass-xterm-wrapper since we
don't have an xterm, or ?

- creating a new location with parameters works, but with the following
issues:

     - the mapset created at the end of the procedure is not a valid
mapset as it does not contain all the necessary files
     - when creating a lat-long location, it jumps immediately from the
one-line description to the region extension, without letting me
define the ellipsoid or other parameters. After the region
definition, it creates the location, but emits a warning that the
"projection information files were not created".

I'll keep trying whenever I have some time.

Moritz

3

Here are some more issues:

- export map canvas to graphics file:

couldn't execute "rm": no such file or directory
couldn't execute "rm": no such file or directory
    while executing
"exec rm $path.ppm"
    ("jpg" arm line 7)
    invoked from within
"switch $type {
      "ppm" {
        return
      }
      "tif" {
        exec gdal_translate $path.ppm $path.tif -of GTIFF
        exec rm $path.ppm
      }
      "bmp" {
        e..."
    (procedure "MapToolBar::savefile" line 22)
    invoked from within
"MapToolBar::savefile jpg 50"
    (menu invoke)

So, graphics file gets created, but the original ppm file is not erased.

- In an earlier mail I wrote: "I noticed that I can close the com.exe
window and still continue using grass. Is there any reason to keep this
open ? If not, is there a way to close it automatically ? Just a question
of not multiplying unnecessary windows."

Actually, I imagine that this window could potentially be used for
scripting, or ? But gis.m does not background itself, so I don't have a
prompt in the com.exe window. Is this linked to Hamish' recent changes
taking away the "&" ?

Moritz

4

Moritz Lennert wrote:

- trying to create a new location from a georeferenced file or from an
EPSG code, I get:

couldn't execute "c:\grass\grass-6.3.cvs\etc\grass-xterm-wrapper": no such
file or directory

I imagine that wingrass should'nt even call grass-xterm-wrapper since we
don't have an xterm, or ?

It may suffice to set GRASS_XTERM to a command which is compatible
with an xterm, e.g. a batch file which ignores everything before the
"-e" switch and runs the command which follows it in a Windows console
(e.g. using the "start" command).

Ideally, on Windows, grass-xterm-wrapper should be a .bat/.cmd script
which ignores GRASS_XTERM and does this automatically.

Programs which use a console for simple printf/fgets-style dialogue
should work in either a Windows console or rxvt (xterm, etc), but
programs which use pdcurses will only work in a console.

The Windows console (and DOS) have specific operations for setting
colours etc, whereas conventional terminals (and Unix curses
implementations) use escape sequences embedded within the text sent to
the terminal. Consequently, programs which use a port of a Unix-style
curses library will work in an rxvt (etc) but not a console, while
programs which use pdcurses will work in a console but not an rxvt.

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

5

Moritz

On 12/18/06 4:23 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

And some more issues:

- trying to create a new location from a georeferenced file or from an
EPSG code, I get:

couldn't execute "c:\grass\grass-6.3.cvs\etc\grass-xterm-wrapper": no such
file or directory
couldn't execute "c:\grass\grass-6.3.cvs\etc\grass-xterm-wrapper": no such
file or directory
    while executing
"exec -- $env(GISBASE)/etc/grass-xterm-wrapper -T g.proj -n g.proj -e
$env(GISBASE)/etc/grass-run.sh g.proj -c georef=$filepath
location=$fileLocation"
    invoked from within
".fileloc.def invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 24)
    invoked from within
"tk::ButtonUp .fileloc.def"
    (command bound to event)

I imagine that wingrass should'nt even call grass-xterm-wrapper since we
don't have an xterm, or ?

What is going on here is a call to execute a bash script that is currently a
workaround to a g.proj requirement to have a preexisting and valid
GISDBASE/location/mapset/WIND suite before it will create a new location.

I think a change to g.proj is in process that would eliminate the need for
this script.

I've got a much better version of the EPSG module ready to go once this is
done. It will now let you search on any term and automatically returns the
EPSG code.

- creating a new location with parameters works, but with the following
issues:

     - the mapset created at the end of the procedure is not a valid
mapset as it does not contain all the necessary files
     - when creating a lat-long location, it jumps immediately from the
one-line description to the region extension, without letting me
define the ellipsoid or other parameters. After the region
definition, it creates the location, but emits a warning that the
"projection information files were not created".

I'll keep trying whenever I have some time.

Good luck on this part. Glynn made a very rational suggestion awhile back.
Why not combine the various projection/ellipse file needed to create a new
location into a single, easily parsable file, with PROJ4-type projection
definitions. Then (with the planned update to g.proj) we could simply have a
GUI that lists projection parameters to be selected and sends the PROJ
string to g.proj.

Now that I've done a search engine for EPSG, the same thing could be done
for the other GRASS projection files. I'm not sure which of the many ascii
projection/ellipse files are actually needed or how they should be combined,
however. Anyone want to take this on?

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

6

Mea culpa on this. Written before we (I) realized the issues this kind of
call to a unix command would cause for Windows. I'll change this to a pure
TclTk call that will work in all platforms.

Along this line, in mapprint.tcl, I used ...

cat [filename] | gs [ghostscript flags and arguments]

... For postscript printing.

Does ghostscript work for Windows? If so, any ideas of a substitute for the
"cat [filename] | gs ..." syntax that would work on Windows?

Michael

On 12/18/06 7:22 AM, "Moritz Lennert" <mlennert@club.worldonline.be> wrote:

Here are some more issues:

- export map canvas to graphics file:

couldn't execute "rm": no such file or directory
couldn't execute "rm": no such file or directory
    while executing
"exec rm $path.ppm"
    ("jpg" arm line 7)
    invoked from within
"switch $type {
"ppm" {
return
}
"tif" {
exec gdal_translate $path.ppm $path.tif -of GTIFF
exec rm $path.ppm
}
"bmp" {
e..."
    (procedure "MapToolBar::savefile" line 22)
    invoked from within
"MapToolBar::savefile jpg 50"
    (menu invoke)

So, graphics file gets created, but the original ppm file is not erased.

- In an earlier mail I wrote: "I noticed that I can close the com.exe
window and still continue using grass. Is there any reason to keep this
open ? If not, is there a way to close it automatically ? Just a question
of not multiplying unnecessary windows."

Actually, I imagine that this window could potentially be used for
scripting, or ? But gis.m does not background itself, so I don't have a
prompt in the com.exe window. Is this linked to Hamish' recent changes
taking away the "&" ?

Moritz

__________________________________________
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

7

Michael Barton wrote:

Good luck on this part. Glynn made a very rational suggestion awhile back.
Why not combine the various projection/ellipse file needed to create a new
location into a single, easily parsable file, with PROJ4-type projection
definitions. Then (with the planned update to g.proj) we could simply have a
GUI that lists projection parameters to be selected and sends the PROJ
string to g.proj.

Are you referring to the proj-*.table files I created for g.setproj?

Those should be relatively straightforward to use from within a GUI.
The relevant files (all installed into $GISBASE/etc) are:

1. proj-parms.table

One line for each known projection. A sample entry:

  AEA:LAT0=ask,23.0;LAT1=ask,29.5;LAT2=ask,45.5;LON0=ask,-96.0;X0=ask,0.0;Y0=ask,0.0

The first field is the projection name, as used by the old geo.h file.
AFAICT, the corresponding +proj= parameter is identical except in
lower case.

The remainder of the line (after the colon) is a semicolon-separated
list of parameter definitions of the form parm=spec. The LHS is the
parameter name as used by geo.h; these don't necessarily match the
corresponding the proj parameter, but you can translate them using the
proj-desc.table file (see below).

The RHS has two parts, separated by a comma. The first part is either
"ask" or "noask", corresponding to whether or not g.setproj should
prompt the user for a value. The second part is either "nodfl" or a
default value. Note that the combination "noask,nodfl" never occurs;
if an option is marked as "noask", there will always be a default
value.

Ideally, this file should be extended to include a more verbose form
of the projection's name. This can probably be done fairly easily
using the output from "proj -lp". I'll look into this part.

2. proj-desc.table

One line for each known parameter (other than +proj=). A sample entry:

  LON0:lon:lon_0:Central Meridian

The first field is the parameter name as used by the old geo.h file,
and as used in proj-parms.table.

The second field is the type, and can be one of:

  bool int float lat lon zone

This determines the set of valid options for the parameter (the "zone"
type corresponds to the UTM zone).

The third field is the name of the corresponding proj parameter
(without the leading "+"), and is the key stored in the PROJ_INFO
file.

The fourth field is a textual description of the parameter.

3. proj-units.table

One line for each known distance unit. A sample entry:

  feet:foot:0.3048

The three fields are (in case it isn't obvious) the plural form of the
name, the singular form, and the size of the unit in metres.

I'm not sure how this is used by g.setproj, but it can't be that
critical because the code actually tries to load proj-unit.table
(missing "s"). I'll fix this.

proj-parms.table can be used to allow selecting a projection from a
list, while a combination of proj-parms.table and proj-desc.table
would support the creation of a customised dialogue for a given
projection.

However, note that g.setproj still has a fair number of special-case
hacks. Some of those are useful-but-not-essential (e.g. automatically
selecting the correct ellipsoid for certain projections), while others
are necessary (e.g. the zone= and south parameters for UTM need to go
into the WIND/DEFAULT_WIND files as well as the PROJ_INFO file).

Now that I've done a search engine for EPSG, the same thing could be done
for the other GRASS projection files. I'm not sure which of the many ascii
projection/ellipse files are actually needed or how they should be combined,
however.

ellipse.table and datum.table are obvious candidates.

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

8

Michael Barton wrote:

Mea culpa on this. Written before we (I) realized the issues this kind of
call to a unix command would cause for Windows. I'll change this to a pure
TclTk call that will work in all platforms.

Along this line, in mapprint.tcl, I used ...

cat [filename] | gs [ghostscript flags and arguments]

... For postscript printing.

Does ghostscript work for Windows?

Yes.

If so, any ideas of a substitute for the
"cat [filename] | gs ..." syntax that would work on Windows?

Well, "gs ... filename.ps" is normally preferable to using a pipe on
any platform.

However, there are a few differences between the native Windows
version of Ghostscript and the Unix version; according to the Use.htm
file:

  9.3 MS Windows
  
  The name of the Ghostscript command line executable on MS Windows is
  gswin32c so use this instead of the plain 'gs' in the quickstart
  examples.
  
  You must add gs\bin and gs\lib to the PATH, where gs is the top-level
  Ghostscript directory.
  
  When passing options to ghostcript through a batch file wrapper such
  as ps2pdf.bat you need to substitute '#' for '=' as the separator
  between options and their arguments. For example:
  
      ps2pdf -sPAPERSIZE#a4 file.ps file.pdf
  
  Ghostscript treats '#' the same internally, and the '=' is mangled by
  the command shell.
  
  There is also an older version for windows called just gswin32 that
  provides its own window for the interactive postscript prompt. Except
  on Windows 3.1, gswin32c is the better option since it uses the native
  command prompt window.

Note that this only applies to the native Windows version; Cygwin's
Ghostscript package behaves identically to the Unix version.

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

9

Glynn,

On 12/18/06 10:39 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Yes.

If so, any ideas of a substitute for the
"cat [filename] | gs ..." syntax that would work on Windows?

Well, "gs ... filename.ps" is normally preferable to using a pipe on
any platform.

OK. I may have had problems with this syntax, hence the pipe. But I'll try
again.

However, there are a few differences between the native Windows
version of Ghostscript and the Unix version; according to the Use.htm
file:

9.3 MS Windows

The name of the Ghostscript command line executable on MS Windows is
gswin32c so use this instead of the plain 'gs' in the quickstart
examples.

You must add gs\bin and gs\lib to the PATH, where gs is the top-level
Ghostscript directory.

When passing options to ghostcript through a batch file wrapper such
as ps2pdf.bat you need to substitute '#' for '=' as the separator
between options and their arguments. For example:

   ps2pdf -sPAPERSIZE#a4 file.ps file.pdf

Will this work for all versions (*nix as well as Win)? If so, I can just
change it universally and not worry about whether it is on a windows systems
or not.

Ghostscript treats '#' the same internally, and the '=' is mangled by
the command shell.

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

10

Glynn Clements wrote:

1. proj-parms.table

One line for each known projection. A sample entry:

  AEA:LAT0=ask,23.0;LAT1=ask,29.5;LAT2=ask,45.5;LON0=ask,-96.0;X0=ask,0.0;Y0=ask,0.0

Ideally, this file should be extended to include a more verbose form
of the projection's name. This can probably be done fairly easily
using the output from "proj -lp". I'll look into this part.

I've done this part, with the projection's full name between the
abbreviated name and the parameter descriptions, so the format is now
e.g.:

  AEA:Albers Equal Area:LAT0=ask,23.0;LAT1=ask,29.5;LAT2=ask,45.5;LON0=ask,-96.0;X0=ask,0.0;Y0=ask,0.0

3. proj-units.table

I'm not sure how this is used by g.setproj, but it can't be that
critical because the code actually tries to load proj-unit.table
(missing "s"). I'll fix this.

Done.

As for why it wasn't noticed, that's probably because most people just
press Enter to use the default (meter/meters), which skips the use of
that table.

BTW, I'm wondering whether the following entries should be kept:

  nanometers:nanometer:1.000000e-09
  microns:micron:1.000000e-06
  angstroms:angstrom:1.000000e-10
  decinanometers:decinanometer:1.000000e-10
  lightyears:lightyear:9.460530e+15

I presume that these were included as a joke, given that microns are
included yet millimetres are omitted.

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

11

Michael Barton wrote:

> 9.3 MS Windows
>
> The name of the Ghostscript command line executable on MS Windows is
> gswin32c so use this instead of the plain 'gs' in the quickstart
> examples.
>
> You must add gs\bin and gs\lib to the PATH, where gs is the top-level
> Ghostscript directory.
>
> When passing options to ghostcript through a batch file wrapper such
> as ps2pdf.bat you need to substitute '#' for '=' as the separator
> between options and their arguments. For example:
>
> ps2pdf -sPAPERSIZE#a4 file.ps file.pdf

Will this work for all versions (*nix as well as Win)? If so, I can just
change it universally and not worry about whether it is on a windows systems
or not.

It seems to; e.g. "gs -sDEVICE#nullpage" works for me on Linux.

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

12

OK. Thanks. I'll put up a version to test momentarily.

Michael

On 12/18/06 11:50 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

9.3 MS Windows

The name of the Ghostscript command line executable on MS Windows is
gswin32c so use this instead of the plain 'gs' in the quickstart
examples.

You must add gs\bin and gs\lib to the PATH, where gs is the top-level
Ghostscript directory.

When passing options to ghostcript through a batch file wrapper such
as ps2pdf.bat you need to substitute '#' for '=' as the separator
between options and their arguments. For example:

   ps2pdf -sPAPERSIZE#a4 file.ps file.pdf

Will this work for all versions (*nix as well as Win)? If so, I can just
change it universally and not worry about whether it is on a windows systems
or not.

It seems to; e.g. "gs -sDEVICE#nullpage" works for me on Linux.

__________________________________________
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

13

I just committed new windows-compatible versions of mapprint.tcl and
maptool.tcl.

Both work on my Mac (meaning I don't think I broke the x11 version). Please
test for Windows.

Michael

On 12/18/06 11:50 AM, "Glynn Clements" <glynn@gclements.plus.com> wrote:

Michael Barton wrote:

9.3 MS Windows

The name of the Ghostscript command line executable on MS Windows is
gswin32c so use this instead of the plain 'gs' in the quickstart
examples.

You must add gs\bin and gs\lib to the PATH, where gs is the top-level
Ghostscript directory.

When passing options to ghostcript through a batch file wrapper such
as ps2pdf.bat you need to substitute '#' for '=' as the separator
between options and their arguments. For example:

   ps2pdf -sPAPERSIZE#a4 file.ps file.pdf

Will this work for all versions (*nix as well as Win)? If so, I can just
change it universally and not worry about whether it is on a windows systems
or not.

It seems to; e.g. "gs -sDEVICE#nullpage" works for me on Linux.

__________________________________________
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

14

On 18/12/06 19:59, Michael Barton wrote:

I just committed new windows-compatible versions of mapprint.tcl and
maptool.tcl.

Both work on my Mac (meaning I don't think I broke the x11 version). Please
test for Windows.

I have to leave the office now, and am going on vacation tomorrow. I hope to find some time to spend with wingrass during vacation, but am not sure, so if someone else could do some testing, this would be very helpful.

With Paul's library tarball and instructions (http://grass.itc.it/pipermail/grass5/2006-December/027998.html) compilation is beginning to become fairly early.

Here are some additional hints:

- You don't need to get flex from gnuwin32, the msys version available here works as well:
http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=82724&release_id=158862

- For compilation to work, you need to set your path in msys in order to add the path to the lib/ and bin/ directories of Paul's tarball before compiling.

- erase $(MANDIR) $(MANPAGES) from line 13 of man/Makefile, i.e.

default: $(MANDIR) $(MANPAGES)

becomes

default:

Otherwise compilation will stop with an error.

- If you get an error such as

cannot open file `/msys/share/bison/m4sugar/m4sugar.m4': No such file or
>> directory
>> make[3]: *** [y.tab.h] Error 1

you will need to move around the msys bison installation a bit, so that m4sugar.m4 is available in the indicated path. There must be a more elegant way to handle this, but I did not take the time to find it.

- After compilation, in addition to Paul's post-installation instructions, you also might need to include a set GRASS_WISH command in the grass63.bat file.

- If you want to try a make install, after doing this, you need to copy dist.*/demolocation to your new grass installation path.

- If startup doesn't work, always retry first after erasing the .grassrc6 file.

The major issues at this point seem to be startup (which is being worked on) and problems with the dbmi protocols. Glynn hinted at a way this could be solved (http://grass.itc.it/pipermail/grass5/2006-December/028069.html)

Moritz

15

On Mon, 18 Dec 2006, Glynn Clements wrote:

Moritz Lennert wrote:

- trying to create a new location from a georeferenced file or from an
EPSG code, I get:

couldn't execute "c:\grass\grass-6.3.cvs\etc\grass-xterm-wrapper": no such
file or directory

I imagine that wingrass should'nt even call grass-xterm-wrapper since we
don't have an xterm, or ?

It may suffice to set GRASS_XTERM to a command which is compatible
with an xterm, e.g. a batch file which ignores everything before the
"-e" switch and runs the command which follows it in a Windows console
(e.g. using the "start" command).

Ideally, on Windows, grass-xterm-wrapper should be a .bat/.cmd script
which ignores GRASS_XTERM and does this automatically.

This is the way I have handled a similar thing in lib/gtcltk/gronsole.tcl (for the "Run in xterm" button in the gis.m command Window):

   if { $mingw == "1" } {
       exec -- cmd.exe /c start $env(GISBASE)/etc/grass-run.bat $cmd &
   } else {
       exec -- $env(GISBASE)/etc/grass-xterm-wrapper -name xterm-grass -e $env(GISBASE)/etc/grass-run.sh $cmd &
   }

where grass-run.bat sets the console Window title, forces terminal parser mode, runs the command, pauses at the end and prints a note if the command has exited with a non-zero return value. Just a duplicate of the functionality of grass-run.sh really.

Setting the GRASS_XTERM variable to a suitable value that it works on Windows without the $mingw check in the Tcl script sounds like a neat idea however if it works.

Programs which use a console for simple printf/fgets-style dialogue
should work in either a Windows console or rxvt (xterm, etc), but
programs which use pdcurses will only work in a console.

Well I have set it to explicitly use a Windows console. So I guess if someone compiles using something other than pdcurses that would be a problem. But perhaps not one worth worrying about.

Paul

16

Paul Kelly wrote:

> Ideally, on Windows, grass-xterm-wrapper should be a .bat/.cmd script
> which ignores GRASS_XTERM and does this automatically.

This is the way I have handled a similar thing in lib/gtcltk/gronsole.tcl
(for the "Run in xterm" button in the gis.m command Window):

   if { $mingw == "1" } {
       exec -- cmd.exe /c start $env(GISBASE)/etc/grass-run.bat $cmd &
   } else {
       exec -- $env(GISBASE)/etc/grass-xterm-wrapper -name xterm-grass -e $env(GISBASE)/etc/grass-run.sh $cmd &
   }

where grass-run.bat sets the console Window title, forces terminal parser
mode, runs the command, pauses at the end and prints a note if the command
has exited with a non-zero return value. Just a duplicate of the
functionality of grass-run.sh really.

Setting the GRASS_XTERM variable to a suitable value that it works on
Windows without the $mingw check in the Tcl script sounds like a neat idea
however if it works.

If it works, a grass-xterm-wrapper.bat file would work for everything
which currently uses grass-xterm-wrapper without the need for the user
to set GRASS_XTERM. Actually, setting GRASS_XTERM relies upon the
existing grass-xterm-wrapper shell script getting run, which
presumably won't happen on MinGW?

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

17

On Mon, 18 Dec 2006, Moritz Lennert wrote:

Here are some more issues:

- export map canvas to graphics file:

couldn't execute "rm": no such file or directory
   while executing
"exec rm $path.ppm"
   ("jpg" arm line 7)
   invoked from within
"switch $type {
      "ppm" {
        return
      }
      "tif" {
        exec gdal_translate $path.ppm $path.tif

-of GTIFF

        exec rm $path.ppm
      }
      "bmp" {
        e..."
   (procedure "MapToolBar::savefile" line 22)
   invoked from within
"MapToolBar::savefile jpg 50"
   (menu invoke)

So, graphics file gets created, but the original ppm file is not erased.

I think Michael has fixed those occurences of exec rm now so the Tcl file delete function is used. So it should be OK.

- In an earlier mail I wrote: "I noticed that I can close the com.exe
window and still continue using grass. Is there any reason to keep this
open ? If not, is there a way to close it automatically ? Just a question
of not multiplying unnecessary windows."

Actually, I imagine that this window could potentially be used for
scripting, or ? But gis.m does not background itself, so I don't have a
prompt in the com.exe window. Is this linked to Hamish' recent changes
taking away the "&" ?

Moritz

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev

18

Hello Moritz
Better late than never to respond to some of these issues.
(Sorry about that last mail; sent it far too soon...)

On Mon, 18 Dec 2006, Moritz Lennert wrote:

Here are some more issues:

[...]

Did that. I also added a 'set GRASS_WISH=' command in grass63.bat, as it
didn't seem to find my wish command.

Right. init.bat will need to be changed to set GRASS_WISH by default I
think - I was under the impression that it only needed to be set if the
wish executable wasn't in the path, but there seem to be places in gis.m
and nviz that rely on it being set and crash if it isn't. FWIW with the
Activestate Tcl/Tk that I was using there are executables named both
wish.exe and wish84.exe, which are identical. With the MinGW Tcl/Tk there
is only wish84.exe.

Now, to go on:

- I had hoped that Radim's patch for dbmi_client
(http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might
solve the issue I've had with the db protocol errors, but apparently this
is not the case. When I push the 'show the attribute columns' in a vector
panel, I still get

*******
Displaying column types/names for database connection of layer 1:
dbmi: Protocol error

Cannot open table <streams>
********

and a 'v.db.select' on the same map gives me:

********
'vector/streams' was found in more mapsets (also found in user1).
dbmi: Protocol error

Cannot open select cursor
*********

Radim, as you have been working on this these days, do you have an idea
what might be wrong ?

I can confirm similar problems. I tried to import a Shapefile with
v.in.ogr. I went quite deep into debugging it and got nowhere at all,
although I should have taken better notes. I did confirm though that
compiling the library with -mwindows as Radim suggested on the list made
no difference either. I think trying with a different database, PostgreSQL
perhaps is the next big step to debugging this. See if the behaviour is
the same as with dbf and if not we can isolate it a bit more.
(Markus, this is what you were asking about what would be the next step
towards solving this.)

- I noticed that I can close the com.exe window and still continue using
grass. Is there any reason to keep this open ? If not, is there a way to
close it automatically ? Just a question of not multiplying unnecessary
windows.

It is running init.bat. When gis.m exits then etc/clean_temp will be run
to clean up the temporary files. It is possible to minmise it (by editing
the properties of the shortcut to grass63.bat) but I don't know how to
make it disappear.

- Help does not work. In individual command windows, the help button is
desactivated. In layer panels in the main GIS Manager window, when I push
the help button, I get:

child process exited abnormally
   while executing
"exec -- g.manual d.vect >& NUL:"
   ("eval" body line 1)
   invoked from within
"eval [list exec -- $cmd] $args >& $devnull"
   (procedure "run" line 8)
   invoked from within
"run g.manual d.vect"
   ("uplevel" body line 1)
   invoked from within
"uplevel \#0 $cmd"
   (procedure "Button::_release" line 18)
   invoked from within
"Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e"
   (command bound to event)

This was due to g.parser assuming the shell (c:\msys\1.0\bin\sh.exe) that
it needed to run g.manual (required for all the help) was in the path. I
have since changed the way it operates on Windows to first check the
environment variable GRASS_SH before looking for sh.exe in the path. So
the help should work now.

- export map canvas to graphics file:

couldn't execute "rm": no such file or directory
   while executing
"exec rm $path.ppm"
   ("jpg" arm line 7)
   invoked from within
"switch $type {
                      "ppm" {
                              return
                      }
                      "tif" {
                              exec gdal_translate $path.ppm $path.tif -of GTI$
                              exec rm $path.ppm
                      }
                      "bmp" {
                              e..."
   (procedure "MapToolBar::savefile" line 22)
   invoked from within
"MapToolBar::savefile jpg 50"
   (menu invoke)

So, graphics file gets created, but the original ppm file is not erased.

I think Michael has fixed those occurences of exec rm now so the Tcl file
delete function is used. So it should be OK.

Another outstanding issue is Nviz. It was working on Windows for a while
(looked great with Michael's new user interface improvements) but since Bob changed it back to the script startup rather than running the nviz.exe
executable directly it no longer works on Windows. In fact I recently tried to revert those changes and found it still wouldn't work; got stuck at the Please Wait screen. A pity, because there is probably very little needs changed to have it working again.

There are also a few other things that need tidying up. Having backslashes
instead of forward slashes in the setting of WINGISBASE in grass63.bat is
an obvious one. Should be really simple with use of sed in the Makefile
but I couldn't get it to work.

More later.

Paul

19

I have a problem like this on versions of GRASS that I compile myself on my
Mac. It doesn't happen on versions that William Kyngesbury compiles. In my
case, all of GRASS is correctly compiling against an x11 tcltk that I
specify, but nviz insists on compiling against an aqua version also on my
machine. It creates a bad nviz binary file (the one that Bob's script
calls). I can substitute one that William compiles and all is well. Maybe
something similar is happening to you?

Michael

On 2/6/07 5:39 PM, "Paul Kelly" <paul-grass@stjohnspoint.co.uk> wrote:

Another outstanding issue is Nviz. It was working on Windows for a while
(looked great with Michael's new user interface improvements) but since
Bob changed it back to the script startup rather than running the nviz.exe
executable directly it no longer works on Windows. In fact I recently
tried to revert those changes and found it still wouldn't work; got stuck
at the Please Wait screen. A pity, because there is probably very little
needs changed to have it working again.

__________________________________________
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

20

Paul, Moritz, all,

I have added the vector-DB problem to
  http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status#What_is_missing.3F
My suggestion is to maintain the list there updated.

Markus

Paul Kelly wrote on 02/07/2007 01:39 AM:

Hello Moritz
Better late than never to respond to some of these issues.
(Sorry about that last mail; sent it far too soon...)

On Mon, 18 Dec 2006, Moritz Lennert wrote:

Here are some more issues:

[...]

Did that. I also added a 'set GRASS_WISH=' command in grass63.bat, as it
didn't seem to find my wish command.

Right. init.bat will need to be changed to set GRASS_WISH by default I
think - I was under the impression that it only needed to be set if the
wish executable wasn't in the path, but there seem to be places in gis.m
and nviz that rely on it being set and crash if it isn't. FWIW with the
Activestate Tcl/Tk that I was using there are executables named both
wish.exe and wish84.exe, which are identical. With the MinGW Tcl/Tk there
is only wish84.exe.

Now, to go on:

- I had hoped that Radim's patch for dbmi_client
(http://grass.itc.it/pipermail/grass5/2006-December/028118.html) might
solve the issue I've had with the db protocol errors, but apparently this
is not the case. When I push the 'show the attribute columns' in a vector
panel, I still get

*******
Displaying column types/names for database connection of layer 1:
dbmi: Protocol error

Cannot open table <streams>
********

and a 'v.db.select' on the same map gives me:

********
'vector/streams' was found in more mapsets (also found in user1).
dbmi: Protocol error

Cannot open select cursor
*********

Radim, as you have been working on this these days, do you have an idea
what might be wrong ?

I can confirm similar problems. I tried to import a Shapefile with
v.in.ogr. I went quite deep into debugging it and got nowhere at all,
although I should have taken better notes. I did confirm though that
compiling the library with -mwindows as Radim suggested on the list made
no difference either. I think trying with a different database, PostgreSQL
perhaps is the next big step to debugging this. See if the behaviour is
the same as with dbf and if not we can isolate it a bit more.
(Markus, this is what you were asking about what would be the next step
towards solving this.)

- I noticed that I can close the com.exe window and still continue using
grass. Is there any reason to keep this open ? If not, is there a way to
close it automatically ? Just a question of not multiplying unnecessary
windows.

It is running init.bat. When gis.m exits then etc/clean_temp will be run
to clean up the temporary files. It is possible to minmise it (by editing
the properties of the shortcut to grass63.bat) but I don't know how to
make it disappear.

- Help does not work. In individual command windows, the help button is
desactivated. In layer panels in the main GIS Manager window, when I push
the help button, I get:

child process exited abnormally
   while executing
"exec -- g.manual d.vect >& NUL:"
   ("eval" body line 1)
   invoked from within
"eval [list exec -- $cmd] $args >& $devnull"
   (procedure "run" line 8)
   invoked from within
"run g.manual d.vect"
   ("uplevel" body line 1)
   invoked from within
"uplevel \#0 $cmd"
   (procedure "Button::_release" line 18)
   invoked from within
"Button::_release .mainframe.frame.pw1.f1.frame.sw.sf.frame.fr.name.e"
   (command bound to event)

This was due to g.parser assuming the shell (c:\msys\1.0\bin\sh.exe) that
it needed to run g.manual (required for all the help) was in the path. I
have since changed the way it operates on Windows to first check the
environment variable GRASS_SH before looking for sh.exe in the path. So
the help should work now.

- export map canvas to graphics file:

couldn't execute "rm": no such file or directory
   while executing
"exec rm $path.ppm"
   ("jpg" arm line 7)
   invoked from within
"switch $type {
                      "ppm" {
                              return
                      }
                      "tif" {
                              exec gdal_translate $path.ppm $path.tif -of GTI$
                              exec rm $path.ppm
                      }
                      "bmp" {
                              e..."
   (procedure "MapToolBar::savefile" line 22)
   invoked from within
"MapToolBar::savefile jpg 50"
   (menu invoke)

So, graphics file gets created, but the original ppm file is not erased.

I think Michael has fixed those occurences of exec rm now so the Tcl file
delete function is used. So it should be OK.

Another outstanding issue is Nviz. It was working on Windows for a while
(looked great with Michael's new user interface improvements) but since Bob changed it back to the script startup rather than running the nviz.exe
executable directly it no longer works on Windows. In fact I recently tried to revert those changes and found it still wouldn't work; got stuck at the Please Wait screen. A pity, because there is probably very little needs changed to have it working again.

There are also a few other things that need tidying up. Having backslashes
instead of forward slashes in the setting of WINGISBASE in grass63.bat is
an obvious one. Should be really simple with use of sed in the Makefile
but I couldn't get it to work.

More later.

Paul

_______________________________________________
grass-dev mailing list
grass-dev@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass-dev