[GRASS-dev] MS-Windows native GRASS

Hi,

I'm so excited to announce that I've just uploaded a package for
MS-Windows native GRASS at http://geni.ath.cx/grass.html . Rather than
putting everything required for winGRASS in one huge package, I have prepared
a batch file for automatic installation except for MinGW, MSys, and
PostgreSQL, which are distributed as *.exe. I hope it will make easy for
anyone to install winGRASS.

Please note that this first package is considered incomplete and
requires more testing and bug fixing.

Enjoy,
Huidae Cho

On Thu, September 14, 2006 05:56, Huidae Cho wrote:

Hi,

I'm so excited to announce that I've just uploaded a package for
MS-Windows native GRASS at http://geni.ath.cx/grass.html . Rather than
putting everything required for winGRASS in one huge package, I have
prepared
a batch file for automatic installation except for MinGW, MSys, and
PostgreSQL, which are distributed as *.exe. I hope it will make easy for
anyone to install winGRASS.

Congratulations ! At first try, install didn't work (nothing installed
even though it said it did). I then realised that the wget package was not
downloaded correctly. After I downloaded it again, everything went very
smoothly.

Please note that this first package is considered incomplete and
requires more testing and bug fixing.

First impressions:

- had to add c:\mingw\bin in the PATH line of grass.bat, otherwise it
wouldn't find wish84

- cannot create new mapset, I get:

bad option "-permissions": must be -archive, -hidden, -longname,
-readonly, -shortname, or -system
bad option "-permissions": must be -archive, -hidden, -longname,
-readonly, -shortname, or -system
    while executing
"file attributes $mymapset/VAR -permissions u+rw,go+r"
    invoked from within
".frame0.frameNMS.third.button invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 24)
    invoked from within
"tk::ButtonUp .frame0.frameNMS.third.button
"
    (command bound to event)

- any reason why the command line prompt is called 'GRASS-GRID' ?

- great speed compared to cygwin/grass

- for some commands (e.g. query) a console window flashes up very briefly.
No real problem, just a bit annoying.

- displaying a map works fine, but once you have displayed it, you cannot
change any formatting (colors, type, etc) even if you erase the screen, it
always comes back the way it was the first time. This happens with vector,
chart and raster layers (after running r.colors) . If I open a new
display, I can display the map differently. Looks like the .ppm files are
not updated correctly, even though I can see that the d.vect command
changes in the output:

***output***
d.vect map=communes color=0:0:0 lcolor=0:0:0 fcolor=none display=shape
type=point,line,boundary,area icon=basic/x size=5 layer=1 lsize=8
xref=left yref=center llayer=1

g.pnmcomp in=3020.4.ppm,3020.3.ppm mask=3020.4.pgm,3020.3.pgm
opacity=1.00,1.00 background=255:255:255 width=644 height=484
out=3020.1.ppm

d.font romans

d.frame -e

d.frame -e

d.vect map=communes color=153:0:153 lcolor=0:0:0 fcolor=none display=shape
type=point,line,boundary,area icon=basic/x size=5 layer=1 lsize=8
xref=left yref=center llayer=1

g.pnmcomp in=3020.4.ppm,3020.3.ppm mask=3020.4.pgm,3020.3.pgm
opacity=1.00,1.00 background=255:255:255 width=644 height=484
out=3020.1.ppm
****/output****

- trying to display a thematic layer, I get :

can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array
can't read "_data(.gronsole.gronsole,4,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 25)
    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.thematic -s map=communes
type=area column=COMCOD layer=1 icon=basic/circle size=5 maxsize=20
nint=4 po..."
    ("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 "GmThematic::display" line 68)
    invoked from within
"GmThematic::display $node $mod"
    ("thematic" 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)

This is a great beginning. Thanks Huidae !

Moritz

Moritz Lennert wrote:

- cannot create new mapset, I get:

bad option "-permissions": must be -archive, -hidden, -longname,
-readonly, -shortname, or -system

Right; "file attributes ... -permissions ..." is specific to Unix.

That command should be wrapped inside a catch statement; it doesn't
particularly matter if it fails.

- for some commands (e.g. query) a console window flashes up very briefly.
No real problem, just a bit annoying.

There are probably ways around that (e.g. "start /b ..."), but that's
likely to be a relatively low priority for now.

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

This problem also appeared for Mac OSX when running in aqua TclTk instead of
x11 TclTk. I saw that William Kyngesbury had a solution there, but don't
remember what it was.

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: Thu, 14 Sep 2006 11:10:46 +0200 (CEST)
To: Huidae Cho <grass4u@gmail.com>
Cc: <grassuser@grass.itc.it>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] MS-Windows native GRASS

- trying to display a thematic layer, I get :

can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array
can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array
    while executing
"set donecmd $_data($path,$ci,donecmd)"
    (procedure "Gronsole::done_command" line 3)

These files are written to a temp directory within the GRASS
location/mapset, and specified by g.tempfile.

Maybe run g.tempfile and see if it is doing what it is supposed to on
Windows.

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: Thu, 14 Sep 2006 11:10:46 +0200 (CEST)
To: Huidae Cho <grass4u@gmail.com>
Cc: <grassuser@grass.itc.it>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] MS-Windows native GRASS

- displaying a map works fine, but once you have displayed it, you cannot
change any formatting (colors, type, etc) even if you erase the screen, it
always comes back the way it was the first time. This happens with vector,
chart and raster layers (after running r.colors) . If I open a new
display, I can display the map differently. Looks like the .ppm files are
not updated correctly, even though I can see that the d.vect command
changes in the output:

Michael Barton wrote:

This problem also appeared for Mac OSX when running in aqua TclTk instead of
x11 TclTk. I saw that William Kyngesbury had a solution there, but don't
remember what it was.

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

but not sure how this helps for windows.

Moritz

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: Thu, 14 Sep 2006 11:10:46 +0200 (CEST)
To: Huidae Cho <grass4u@gmail.com>
Cc: <grassuser@grass.itc.it>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] MS-Windows native GRASS

- trying to display a thematic layer, I get :

can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array
    while executing
"set donecmd $_data($path,$ci,donecmd)"
    (procedure "Gronsole::done_command" line 3)

I don't either, but it's the same error. If William figured out why this was
happening on the Mac, it may lead to a solution on Windows.

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: Thu, 14 Sep 2006 16:56:28 +0200
To: Michael Barton <michael.barton@asu.edu>
Cc: Huidae Cho <grass4u@gmail.com>, <grassuser@grass.itc.it>,
<grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] MS-Windows native GRASS

Michael Barton wrote:

This problem also appeared for Mac OSX when running in aqua TclTk instead of
x11 TclTk. I saw that William Kyngesbury had a solution there, but don't
remember what it was.

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

but not sure how this helps for windows.

Moritz

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: Thu, 14 Sep 2006 11:10:46 +0200 (CEST)
To: Huidae Cho <grass4u@gmail.com>
Cc: <grassuser@grass.itc.it>, <grass-dev@grass.itc.it>
Subject: Re: [GRASS-dev] MS-Windows native GRASS

- trying to display a thematic layer, I get :

can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array
can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array
    while executing
"set donecmd $_data($path,$ci,donecmd)"
    (procedure "Gronsole::done_command" line 3)

Thank you. Actually, I don't have enough time to test/bugfix winGRASS,
so I've created a wiki page describing its current status:
http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status

If you find any problems not listed here, please add them to the page so
that I can catch up later with what's wrong.

Huidae

On Thu, Sep 14, 2006 at 07:55:59AM -0700, Teague O'Mara wrote:

Wow Huidae. I can't wait to test this out. Thanks for putting it together. It
must have taken an extraordinarly amount of work.

Thanks,

Teague

Teague O'Mara
School of Human Evolution and Social Change
Arizona State University
Box 872402
Tempe, AZ 85287-2402
480.965.6213

Quoting Huidae Cho <grass4u@gmail.com>:

> Hi,
>
> I'm so excited to announce that I've just uploaded a package for
> MS-Windows native GRASS at http://geni.ath.cx/grass.html . Rather
> than
> putting everything required for winGRASS in one huge package, I have
> prepared
> a batch file for automatic installation except for MinGW, MSys, and
> PostgreSQL, which are distributed as *.exe. I hope it will make easy
> for
> anyone to install winGRASS.
>
> Please note that this first package is considered incomplete and
> requires more testing and bug fixing.
>
> Enjoy,
> Huidae Cho
>
> _______________________________________________
> winGRASS mailing list
> winGRASS@grass.itc.it
> http://grass.itc.it/mailman/listinfo/wingrass
>

The OSX fix is to set osxaqua=1 in the env. It's something Lorenzo added that does a few things different for TclTk X11 vs Aqua on OSX. You may get some clue to the Windows problem by searching for osxaqua in the scripts (including init.sh). A noticable difference was use of spawn vs term (or some such thing).

On Sep 14, 2006, at 10:14 AM, Michael Barton wrote:

I don't either, but it's the same error. If William figured out why this was
happening on the Mac, it may lead to a solution on Windows.

Michael Barton wrote:

This problem also appeared for Mac OSX when running in aqua TclTk instead of
x11 TclTk. I saw that William Kyngesbury had a solution there, but don't
remember what it was.

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

but not sure how this helps for windows.

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

"Mon Dieu! but they are all alike. Cheating, murdering, lying, fighting, and all for things that the beasts of the jungle would not deign to possess - money to purchase the effeminate pleasures of weaklings. And yet withal bound down by silly customs that make them slaves to their unhappy lot while firm in the belief that they be the lords of creation enjoying the only real pleasures of existence....

- the wisdom of Tarzan

On Thu, Sep 14, 2006 at 11:10:46AM +0200, Moritz Lennert wrote:

On Thu, September 14, 2006 05:56, Huidae Cho wrote:
> Hi,
>
> I'm so excited to announce that I've just uploaded a package for
> MS-Windows native GRASS at http://geni.ath.cx/grass.html . Rather than
> putting everything required for winGRASS in one huge package, I have
> prepared
> a batch file for automatic installation except for MinGW, MSys, and
> PostgreSQL, which are distributed as *.exe. I hope it will make easy for
> anyone to install winGRASS.

Congratulations ! At first try, install didn't work (nothing installed
even though it said it did). I then realised that the wget package was not
downloaded correctly. After I downloaded it again, everything went very
smoothly.

>
> Please note that this first package is considered incomplete and
> requires more testing and bug fixing.

First impressions:

- had to add c:\mingw\bin in the PATH line of grass.bat, otherwise it
wouldn't find wish84

Did you try to run c:\msys\1.0\msys.bat and check if PATH includes
/mingw/bin? /mingw/bin should be there by default. I think you
installed MSys before MinGW so that MSys does not know about MinGW.
This is why I emphasized installation order.

- cannot create new mapset, I get:

bad option "-permissions": must be -archive, -hidden, -longname,
-readonly, -shortname, or -system
bad option "-permissions": must be -archive, -hidden, -longname,
-readonly, -shortname, or -system
    while executing
"file attributes $mymapset/VAR -permissions u+rw,go+r"
    invoked from within
".frame0.frameNMS.third.button invoke"
    ("uplevel" body line 1)
    invoked from within
"uplevel #0 [list $w invoke]"
    (procedure "tk::ButtonUp" line 24)
    invoked from within
"tk::ButtonUp .frame0.frameNMS.third.button
"
    (command bound to event)

Oops! Sorry, I didn't even try to create a new mapset before
distributing.

- any reason why the command line prompt is called 'GRASS-GRID' ?

I'll change the prompt.

- great speed compared to cygwin/grass

That's great!

- for some commands (e.g. query) a console window flashes up very briefly.
No real problem, just a bit annoying.

As Glynn suggested, "start /b" will do the trick. I'll try this.

- displaying a map works fine, but once you have displayed it, you cannot
change any formatting (colors, type, etc) even if you erase the screen, it
always comes back the way it was the first time. This happens with vector,
chart and raster layers (after running r.colors) . If I open a new
display, I can display the map differently. Looks like the .ppm files are
not updated correctly, even though I can see that the d.vect command
changes in the output:

***output***
d.vect map=communes color=0:0:0 lcolor=0:0:0 fcolor=none display=shape
type=point,line,boundary,area icon=basic/x size=5 layer=1 lsize=8
xref=left yref=center llayer=1

g.pnmcomp in=3020.4.ppm,3020.3.ppm mask=3020.4.pgm,3020.3.pgm
opacity=1.00,1.00 background=255:255:255 width=644 height=484
out=3020.1.ppm

d.font romans

d.frame -e

d.frame -e

d.vect map=communes color=153:0:153 lcolor=0:0:0 fcolor=none display=shape
type=point,line,boundary,area icon=basic/x size=5 layer=1 lsize=8
xref=left yref=center llayer=1

g.pnmcomp in=3020.4.ppm,3020.3.ppm mask=3020.4.pgm,3020.3.pgm
opacity=1.00,1.00 background=255:255:255 width=644 height=484
out=3020.1.ppm
****/output****

This problem looks like the same as zooming/panning bug.

- trying to display a thematic layer, I get :

can't read "_data(.gronsole.gronsole,4,donecmd)": no such element in array
can't read "_data(.gronsole.gronsole,4,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 25)
    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.thematic -s map=communes
type=area column=COMCOD layer=1 icon=basic/circle size=5 maxsize=20
nint=4 po..."
    ("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 "GmThematic::display" line 68)
    invoked from within
"GmThematic::display $node $mod"
    ("thematic" 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)

I know this donecmd bug. I'll look at it.

This is a great beginning. Thanks Huidae !

Moritz

Thanks.
Huidae

Huidae Cho wrote:

On Thu, Sep 14, 2006 at 11:10:46AM +0200, Moritz Lennert wrote:

On Thu, September 14, 2006 05:56, Huidae Cho wrote:

Hi,

I'm so excited to announce that I've just uploaded a package for
MS-Windows native GRASS at http://geni.ath.cx/grass.html . Rather than
putting everything required for winGRASS in one huge package, I have
prepared
a batch file for automatic installation except for MinGW, MSys, and
PostgreSQL, which are distributed as *.exe. I hope it will make easy for
anyone to install winGRASS.

Congratulations ! At first try, install didn't work (nothing installed
even though it said it did). I then realised that the wget package was not
downloaded correctly. After I downloaded it again, everything went very
smoothly.

Please note that this first package is considered incomplete and
requires more testing and bug fixing.

First impressions:

- had to add c:\mingw\bin in the PATH line of grass.bat, otherwise it
wouldn't find wish84

Did you try to run c:\msys\1.0\msys.bat and check if PATH includes
/mingw/bin? /mingw/bin should be there by default. I think you
installed MSys before MinGW so that MSys does not know about MinGW.
This is why I emphasized installation order.

I think I know what might have happened: I probably mistyped the mingw
installation path, giving c:\mingw instead of c:/mingw. Could this be it
? I don't know where to change this in an existing installation, though.

Just redid the install in a windows instance running in qemu on my
computer (this way I don't have to bother my colleagues anymore) and now
it works without changing the path.

Other remarks:

- both the postgresql and the wget links do not work for me. For both I
ahve to go up one level and looking for the files myself.

- grass starts with a warning: "Invalid database." This is not very encouraging for a new user :wink: But the biggest problem is that trying to navigate to a GRASS database which is outside the msys tree (e.g. //Documents and Settings/moritz) gives me a 'no such file or directory' error. If I replace the original '/' in the database navigation text field by c:, then I can navigate to the database without any problems.

- gdal_translate (gdal-bin) is not installed and so you cannot export a map to jpg or other format

- grass opens in the msys home directory. It might be interesting to allow the user to choose in which directory it starts as user would probably prefer to be able to stay withing their usual windows directory structure

- ps.map (simple tests) works great, printing display to eps works great, however, cannot create postscript or PDF output, since GRASS doesn't find ghostscript in its path (it is installed in
Program Files/gs/...). Not sure where to include this path ?

- typing exit at the command line, does not close tcltk windows

More testing to come, but now I have to get back to work :wink:

Moritz

On Fri, Sep 15, 2006 at 12:55:02PM +0200, Moritz Lennert wrote:

Huidae Cho wrote:
>On Thu, Sep 14, 2006 at 11:10:46AM +0200, Moritz Lennert wrote:
>>On Thu, September 14, 2006 05:56, Huidae Cho wrote:
>>>Hi,
>>>I'm so excited to announce that I've just uploaded a package for
>>>MS-Windows native GRASS at http://geni.ath.cx/grass.html . Rather than
>>>putting everything required for winGRASS in one huge package, I have
>>>prepared
>>>a batch file for automatic installation except for MinGW, MSys, and
>>>PostgreSQL, which are distributed as *.exe. I hope it will make easy for
>>>anyone to install winGRASS.
>>Congratulations ! At first try, install didn't work (nothing installed
>>even though it said it did). I then realised that the wget package was not
>>downloaded correctly. After I downloaded it again, everything went very
>>smoothly.
>>>Please note that this first package is considered incomplete and
>>>requires more testing and bug fixing.
>>First impressions:
>>- had to add c:\mingw\bin in the PATH line of grass.bat, otherwise it
>>wouldn't find wish84
>Did you try to run c:\msys\1.0\msys.bat and check if PATH includes
>/mingw/bin? /mingw/bin should be there by default. I think you
>installed MSys before MinGW so that MSys does not know about MinGW.
>This is why I emphasized installation order.

I think I know what might have happened: I probably mistyped the mingw
installation path, giving c:\mingw instead of c:/mingw. Could this be it
? I don't know where to change this in an existing installation, though.

Yes, this is it.

Just redid the install in a windows instance running in qemu on my
computer (this way I don't have to bother my colleagues anymore) and now
it works without changing the path.

Other remarks:

- both the postgresql and the wget links do not work for me. For both I
ahve to go up one level and looking for the files myself.

Fixed the postgresql link. What happens with wget is that the site does
not allow direct link? If you copy & paste the url, it works.

- grass starts with a warning: "Invalid database." This is not very encouraging
for a new user :wink: But the biggest problem is that trying to navigate to a
GRASS database which is outside the msys tree (e.g. //Documents and
Settings/moritz) gives me a 'no such file or directory' error. If I replace the
original '/' in the database navigation text field by c:, then I can navigate
to the database without any problems.

Fixed.

- gdal_translate (gdal-bin) is not installed and so you cannot export a map to
jpg or other format

Fixed.

- grass opens in the msys home directory. It might be interesting to allow the
user to choose in which directory it starts as user would probably prefer to be
able to stay withing their usual windows directory structure

Once you choose a database location, the directory will show up by
default.

- ps.map (simple tests) works great, printing display to eps works great,
however, cannot create postscript or PDF output, since GRASS doesn't find
ghostscript in its path (it is installed in
Program Files/gs/...). Not sure where to include this path ?

It should be just PATH?

- typing exit at the command line, does not close tcltk windows

It's normal. Closing gis.m will also close cmd.exe. But please note
that you should type "exit" in the command line instead of just killing
it. Otherwise, current settings will be lost.

More testing to come, but now I have to get back to work :wink:

Moritz

I've just uploaded today's CVS version and updated sqlite and gdal.

Huidae

On Sun, Sep 17, 2006 at 05:17:20PM +0200, Anders Fahlén wrote:

Hi,

Thanks for the efforts to make a native Windows Grass version:-)

I've tried to download and install the 6.3 CVS, September 15, 2006 release,
following the instructions at http://geni.ath.cx/grass.html, but I'm facing
some difficulties. The inst_grass.bat installation does not work for me. Which
directory is it referred to in section 3 of the installation instructions or
does it not matter?

That doesn't matter if the three files are in the same directory. If
you're not sure where you should download them, just put them in
c:\download. Please make sure you PC is ONLINE when running
inst_grass.bat.

I tried to manually copy the grass.bat file to the C:\msys\1.0\local directory.
However, in this case I cannot enter GRASS as I receive, among others, a
"g.gisenv - Unable to find" error message and the "libintl3.dll" file cannot be
found, when selecting a previously configured "Location". Further, I cannot
find any epsg code file and if I manually add a known and valid epsg code I
receive an error message that the libintl3.dll file is missing. This file,
AFAIK, belongs to the cygwin package.

Presumably I've done something wrong with the installation.

You cannot just copy and run grass.bat without successful inst_grass.bat
since inst_grass.bat downloads/installs several libraries required for
winGRASS to run.

I would appreciate any inputs or clarifications on how to properly install the
native 6.3 CVS GRASS Windows version (the http://geni.ath.cx/grass/grass.zip
file is time-stamped 16:40 Sep 17, 2006, whereas the
http://geni.ath.cx/grass/grass-2006-09-15.zip file is time-stamped 12:28 Sep
18, 2006. They seem to have the same file size - any other differences?).

Those two files are the same. grass.zip is symbolic linked to
grass-2006-09-15.zip.

Huidae

On Sat, September 16, 2006 07:30, Huidae Cho wrote:

On Fri, Sep 15, 2006 at 12:55:02PM +0200, Moritz Lennert wrote:

- grass opens in the msys home directory. It might be interesting to
allow the
user to choose in which directory it starts as user would probably
prefer to be
able to stay withing their usual windows directory structure

Once you choose a database location, the directory will show up by
default.

I was not speaking of the database location directory, but the working
directory that GRASS starts in. By default it goes to /home/username
within the msys tree. This means that any file output goes into this
directory by default. As people normally don't organise their files within
the msys tree, it's just a bit annoying to always have to navigate to your
habitual directories.

I've just uploaded today's CVS version and updated sqlite and gdal.

Great ! Thanks for all the fixes. I'll test tomorrow.

Moritz

On Sun, Sep 17, 2006 at 10:13:21PM +0200, Moritz Lennert wrote:

On Sat, September 16, 2006 07:30, Huidae Cho wrote:
> On Fri, Sep 15, 2006 at 12:55:02PM +0200, Moritz Lennert wrote:

>>
>> - grass opens in the msys home directory. It might be interesting to
>> allow the
>> user to choose in which directory it starts as user would probably
>> prefer to be
>> able to stay withing their usual windows directory structure
>
> Once you choose a database location, the directory will show up by
> default.

I was not speaking of the database location directory, but the working
directory that GRASS starts in. By default it goes to /home/username
within the msys tree. This means that any file output goes into this
directory by default. As people normally don't organise their files within
the msys tree, it's just a bit annoying to always have to navigate to your
habitual directories.

I see what you mean. Maybe gis.m people are interested in this feature.
Michael?

Huidae

>
> I've just uploaded today's CVS version and updated sqlite and gdal.
>

Great ! Thanks for all the fixes. I'll test tomorrow.

Moritz

On Sun, September 17, 2006 22:19, Huidae Cho wrote:

On Sun, Sep 17, 2006 at 10:13:21PM +0200, Moritz Lennert wrote:

On Sat, September 16, 2006 07:30, Huidae Cho wrote:
> On Fri, Sep 15, 2006 at 12:55:02PM +0200, Moritz Lennert wrote:

>>
>> - grass opens in the msys home directory. It might be interesting to
>> allow the
>> user to choose in which directory it starts as user would probably
>> prefer to be
>> able to stay withing their usual windows directory structure
>
> Once you choose a database location, the directory will show up by
> default.

I was not speaking of the database location directory, but the working
directory that GRASS starts in. By default it goes to /home/username
within the msys tree. This means that any file output goes into this
directory by default. As people normally don't organise their files
within
the msys tree, it's just a bit annoying to always have to navigate to
your
habitual directories.

I see what you mean. Maybe gis.m people are interested in this feature.
Michael?

I'm not sure this is a gis.m issue. It is more related to the fact that in
a *nix environment you are likely to start your grass session in your home
directory, whereas in the MS Windows environment, you start it in msys and
msys puts you by default into a home/username directory which is created
automatically during installation and which has nothing to do with the
normal working directories of the user (which are much more arbitrary that
in the *nix environment). I don't know how easy this is, but in my eyes,
the best solution would be to include into the grass.bat a setting
defining the working directory and to include instructions to the use on
how to modify this to their liking.

Moritz

On Mon, Sep 18, 2006 at 12:24:40AM +0200, Moritz Lennert wrote:

On Sun, September 17, 2006 22:19, Huidae Cho wrote:
> On Sun, Sep 17, 2006 at 10:13:21PM +0200, Moritz Lennert wrote:
>> On Sat, September 16, 2006 07:30, Huidae Cho wrote:
>> > On Fri, Sep 15, 2006 at 12:55:02PM +0200, Moritz Lennert wrote:
>>
>> >>
>> >> - grass opens in the msys home directory. It might be interesting to
>> >> allow the
>> >> user to choose in which directory it starts as user would probably
>> >> prefer to be
>> >> able to stay withing their usual windows directory structure
>> >
>> > Once you choose a database location, the directory will show up by
>> > default.
>>
>> I was not speaking of the database location directory, but the working
>> directory that GRASS starts in. By default it goes to /home/username
>> within the msys tree. This means that any file output goes into this
>> directory by default. As people normally don't organise their files
>> within
>> the msys tree, it's just a bit annoying to always have to navigate to
>> your
>> habitual directories.
>>
>
> I see what you mean. Maybe gis.m people are interested in this feature.
> Michael?

I'm not sure this is a gis.m issue. It is more related to the fact that in
a *nix environment you are likely to start your grass session in your home
directory, whereas in the MS Windows environment, you start it in msys and
msys puts you by default into a home/username directory which is created
automatically during installation and which has nothing to do with the
normal working directories of the user (which are much more arbitrary that
in the *nix environment). I don't know how easy this is, but in my eyes,
the best solution would be to include into the grass.bat a setting
defining the working directory and to include instructions to the use on
how to modify this to their liking.

Moritz

With the 2006-09-17 package and new grass.bat, you can choose in which
directory you start. Modify the STARTUP_DIR variable in grass.bat.

Huidae