[GRASS-dev] writing msys capable grass63 startup script

GRASS GIS GRASS GIS developer
1

Hello,

After make install under MinGW, the /bin/grass63 script contains:

GISBASE=c:/grass/grass-6.3.cvs

This does not work when you try to launch GRASS from the msys command line
(not via the grass63.bat native win GRASS startup):

$ ./grass63
./grass63: /c/grass/bin/c:/grass/grass-6.3.cvs/etc/Init.sh: No such file
or dictory

The setting should be:

GISBASE=/c/grass/grass-6.3.cvs

But this needs to be conditionalised in the Makefile to only do this under
MinGW. So:

1) Can we assume that this would work for any shell (other than msys)
someone might use ?

2) How can we conditionalise in the Makefile ?

Moritz

2

On Sun, 20 May 2007, Moritz Lennert wrote:

Hello,

After make install under MinGW, the /bin/grass63 script contains:

GISBASE=c:/grass/grass-6.3.cvs

This does not work when you try to launch GRASS from the msys command line
(not via the grass63.bat native win GRASS startup):

$ ./grass63
./grass63: /c/grass/bin/c:/grass/grass-6.3.cvs/etc/Init.sh: No such file
or dictory

The setting should be:

GISBASE=/c/grass/grass-6.3.cvs

Hello Moritz
I don't have time to look at this in detail now but in the GRASS Makefiless there are now two variables:
$(GISBASE) contains the path to GISBASE in the path syntax of the build system (i.e. Msys)
$(RUN_GISBASE) contains the path to GISBASE in the native path syntax of the host system.

Maybe you could look at varying some combination of these rather than conditionalising things on having Msys installed. E.g. Use $(GISBASE) to generate Init.sh while using $(RUN_GISBASE) to generate init.bat or something like that.

Paul

But this needs to be conditionalised in the Makefile to only do this under
MinGW. So:

1) Can we assume that this would work for any shell (other than msys)
someone might use ?

2) How can we conditionalise in the Makefile ?

Moritz

3

On Sun, May 20, 2007 15:25, Paul Kelly wrote:

On Sun, 20 May 2007, Moritz Lennert wrote:

Hello,

After make install under MinGW, the /bin/grass63 script contains:

GISBASE=c:/grass/grass-6.3.cvs

This does not work when you try to launch GRASS from the msys command
line
(not via the grass63.bat native win GRASS startup):

$ ./grass63
./grass63: /c/grass/bin/c:/grass/grass-6.3.cvs/etc/Init.sh: No such file
or dictory

The setting should be:

GISBASE=/c/grass/grass-6.3.cvs

Hello Moritz
I don't have time to look at this in detail now but in the GRASS
Makefiless there are now two variables:
$(GISBASE) contains the path to GISBASE in the path syntax of the build
system (i.e. Msys)
$(RUN_GISBASE) contains the path to GISBASE in the native path syntax of
the host system.

Maybe you could look at varying some combination of these rather than
conditionalising things on having Msys installed. E.g. Use $(GISBASE) to
generate Init.sh while using $(RUN_GISBASE) to generate init.bat or
something like that.

Ths issue is not about Init.sh or Init.bat, but about grass63 and
grass63.bat, i.e. the startup scripts.

Looking at the Makefiles, I don't really see how this would work (but I
admit that I'm not sure I understand everything correctly). The problem is
actually the definition of GISBASE and WINGISBASE in the real-install part
of the Makefile:

        -sed -e "s#^GISBASE.*#GISBASE=${INST_DIR}#"
${ARCH_BINDIR}/grass${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR} >
${BIND
IR}/grass${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}^M

        -sed -e "s#WINGISBASE=.*#WINGISBASE=${INST_DIR}#"
${ARCH_BINDIR}/grass${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}.ba
t > ${BINDIR}/grass${GRASS_VERSION_MAJOR}${GRASS_VERSION_MINOR}.bat^M

Both of them use ${INST_DIR}, which is defined in
include/Make/Platform.make as
INST_DIR = ${prefix}/grass-6.3.cvs

${prefix} is defined during configure as
prefix = c:/grass

GISBASE in the bin.i686-pc-mingw32 dir is defined as:

/c/grasssrc/grass6/dist.i686-pc-mingw32

so in the "correct" msys syntax, but through the above sed line in the
Makefile it is transformed into native MS Win syntax.

I don't really see how using RUN_GISBASE vs GISBASE will change
anything...It is the prefix variable which needs to be adapted
respectively. But I don't know how.

Moritz

4

On Sun, 20 May 2007, Moritz Lennert wrote:

On Sun, May 20, 2007 15:25, Paul Kelly wrote:

On Sun, 20 May 2007, Moritz Lennert wrote:

Hello,

After make install under MinGW, the /bin/grass63 script contains:

GISBASE=c:/grass/grass-6.3.cvs

This does not work when you try to launch GRASS from the msys command
line
(not via the grass63.bat native win GRASS startup):

$ ./grass63
./grass63: /c/grass/bin/c:/grass/grass-6.3.cvs/etc/Init.sh: No such file
or dictory

The setting should be:

GISBASE=/c/grass/grass-6.3.cvs

Hello Moritz
I don't have time to look at this in detail now but in the GRASS
Makefiless there are now two variables:
$(GISBASE) contains the path to GISBASE in the path syntax of the build
system (i.e. Msys)
$(RUN_GISBASE) contains the path to GISBASE in the native path syntax of
the host system.

Maybe you could look at varying some combination of these rather than
conditionalising things on having Msys installed. E.g. Use $(GISBASE) to
generate Init.sh while using $(RUN_GISBASE) to generate init.bat or
something like that.

Ths issue is not about Init.sh or Init.bat, but about grass63 and
grass63.bat, i.e. the startup scripts.

Looking at the Makefiles, I don't really see how this would work (but I
admit that I'm not sure I understand everything correctly). The problem is
actually the definition of GISBASE and WINGISBASE in the real-install part
of the Makefile:

Ah OK. I was on the wrong track there. But note that the GISBASE setting isn't the real problem - actually it's correct that GISBASE is specified in Windows path syntax because that's what the majority of GRASS modules need. The fact that Msys can't understand it is a wider issue than just the startup scripts - it affects almost all shell scripts within GRASS that do file path manipulation. E.g. scripts that use g.tempfile - it will generate a path in Windows syntax but shell scripts usually assume the path is in Unix syntax. We need a more wider solution to this than changing GISBASE in grass63 - which will get Init.sh to run but then nothing else will work. Unforunately an elegant solution to that has evaded me so far - I'm wary also of making it too Msys-specific. Like I think I said before, I'm wondering if we could also get GRASS working with the Unix toolkit that comes with Microsoft Services for Unix. There are also commercial bourne shell interpreters available for Windows. Would be cool if we could get it to work with them and not be Msys-specific.

I'm afraid the solution to this might be some way off yet. In the meantime you can get started by manually editing the grass63 after installing, but look out for unpredictable behaviour in scripts after that - some work, some don't.

In saying all that I've find the command-line WinGRASS you get by running "grass63.bat -text" (i.e. using cmd.exe instead of sh.exe as the shell) really quite usable so far.

Paul

5

On Sun, May 20, 2007 23:24, Paul Kelly wrote:

On Sun, 20 May 2007, Moritz Lennert wrote:

On Sun, May 20, 2007 15:25, Paul Kelly wrote:

On Sun, 20 May 2007, Moritz Lennert wrote:

Hello,

After make install under MinGW, the /bin/grass63 script contains:

GISBASE=c:/grass/grass-6.3.cvs

This does not work when you try to launch GRASS from the msys command
line
(not via the grass63.bat native win GRASS startup):

$ ./grass63
./grass63: /c/grass/bin/c:/grass/grass-6.3.cvs/etc/Init.sh: No such
file
or dictory

The setting should be:

GISBASE=/c/grass/grass-6.3.cvs

Hello Moritz
I don't have time to look at this in detail now but in the GRASS
Makefiless there are now two variables:
$(GISBASE) contains the path to GISBASE in the path syntax of the build
system (i.e. Msys)
$(RUN_GISBASE) contains the path to GISBASE in the native path syntax
of
the host system.

Maybe you could look at varying some combination of these rather than
conditionalising things on having Msys installed. E.g. Use $(GISBASE)
to
generate Init.sh while using $(RUN_GISBASE) to generate init.bat or
something like that.

Ths issue is not about Init.sh or Init.bat, but about grass63 and
grass63.bat, i.e. the startup scripts.

Looking at the Makefiles, I don't really see how this would work (but I
admit that I'm not sure I understand everything correctly). The problem
is
actually the definition of GISBASE and WINGISBASE in the real-install
part
of the Makefile:

Ah OK. I was on the wrong track there. But note that the GISBASE setting
isn't the real problem - actually it's correct that GISBASE is specified
in Windows path syntax because that's what the majority of GRASS modules
need. The fact that Msys can't understand it is a wider issue than just
the startup scripts - it affects almost all shell scripts within GRASS
that do file path manipulation. E.g. scripts that use g.tempfile - it will
generate a path in Windows syntax but shell scripts usually assume the
path is in Unix syntax. We need a more wider solution to this than
changing GISBASE in grass63 - which will get Init.sh to run but then
nothing else will work. Unforunately an elegant solution to that has
evaded me so far - I'm wary also of making it too Msys-specific. Like I
think I said before, I'm wondering if we could also get GRASS working with
the Unix toolkit that comes with Microsoft Services for Unix. There are
also commercial bourne shell interpreters available for Windows. Would be
cool if we could get it to work with them and not be Msys-specific.

I'm afraid the solution to this might be some way off yet. In the meantime
you can get started by manually editing the grass63 after installing, but
look out for unpredictable behaviour in scripts after that - some work,
some don't.

In saying all that I've find the command-line WinGRASS you get by running
"grass63.bat -text" (i.e. using cmd.exe instead of sh.exe as the shell)
really quite usable so far.

Yes, but this doesn't allow you to execute any scripts, whereas msys does.
But yes, whether they actually work is another question...

So, I'll just leave this as is for now.

Moritz

6

On Mon, 21 May 2007, Moritz Lennert wrote:

[...]

In saying all that I've find the command-line WinGRASS you get by running
"grass63.bat -text" (i.e. using cmd.exe instead of sh.exe as the shell)
really quite usable so far.

Yes, but this doesn't allow you to execute any scripts, whereas msys does.
But yes, whether they actually work is another question...

It works for me. What error messages are you getting or what's the problem exactly? Actually though you need to make sure you have the Msys bin and MinGW bin and lib directories in your PATH, maybe that's it? That's something else I've glossed over and should have mentioned, sorry. Need to look into that further (Msys documentation perhaps???): I'd originally hoped that if you started the Msys shell it would insert its needed directories into the PATH automatically, but that doesn't seem to happen and I never got round to extending the .bat script-launching system to do any path manipulation because, to do that elegantly we need to look at documentation for other Windows ports of bourne shell interpreters and see how they handle being launched in this way, specifically path-related issues.

Paul

7

On Mon, May 21, 2007 00:33, Paul Kelly wrote:

On Mon, 21 May 2007, Moritz Lennert wrote:

[...]

In saying all that I've find the command-line WinGRASS you get by
running
"grass63.bat -text" (i.e. using cmd.exe instead of sh.exe as the shell)
really quite usable so far.

Yes, but this doesn't allow you to execute any scripts, whereas msys
does.
But yes, whether they actually work is another question...

It works for me. What error messages are you getting or what's the problem
exactly?

I just noticed that the path to the msys shell was not correctly defined,
and that was why they did not execute...duh.

Actually though you need to make sure you have the Msys bin and
MinGW bin and lib directories in your PATH, maybe that's it? That's
something else I've glossed over and should have mentioned, sorry. Need to
look into that further (Msys documentation perhaps???)

Setting the path variable works great. I now get scripts to actually work,
using msys' shell tools ! I'll add this to the README of the wingrass
package.

: I'd originally
hoped that if you started the Msys shell it would insert its needed
directories into the PATH automatically, but that doesn't seem to happen
and I never got round to extending the .bat script-launching system to do
any path manipulation because, to do that elegantly we need to look at
documentation for other Windows ports of bourne shell interpreters and see
how they handle being launched in this way, specifically path-related
issues.

Although I agree that we should try to aim for as general as possible,
shouldn't we start by getting winGRASS working nicely with msys as a
requirement and then slowly work away from that ? Or do you fear that this
will make us too lazy and not solve the real issues from the start ?

Moritz

8

On Mon, 21 May 2007, Moritz Lennert wrote:

I just noticed that the path to the msys shell was not correctly defined,
and that was why they did not execute...duh.

Ah yes you also need the GRASS_SH environment variable set properly, which I forgot to mention. It should contain the path to the shell interpreter in Windows path syntax, and is used both by the .bat script launch mechanism and by g.parser when it "re-launches" each script after processing the parser options. For that reason it is also used when WinGRASS is started from Init.sh and it is set both in Init.sh and init.bat, but if you set it before running them then it won't overridden.

Actually though you need to make sure you have the Msys bin and
MinGW bin and lib directories in your PATH, maybe that's it? That's
something else I've glossed over and should have mentioned, sorry. Need to
look into that further (Msys documentation perhaps???)

Setting the path variable works great. I now get scripts to actually work,
using msys' shell tools ! I'll add this to the README of the wingrass
package.

Good to hear. Note it's generally a bad idea (for troubleshooting and developing) to always have the Msys/MinGW directories in your path as then you miss some Unixisms in the code such as system("ls") which will work fine if you have a version of ls in your path.

: I'd originally
hoped that if you started the Msys shell it would insert its needed
directories into the PATH automatically, but that doesn't seem to happen
and I never got round to extending the .bat script-launching system to do
any path manipulation because, to do that elegantly we need to look at
documentation for other Windows ports of bourne shell interpreters and see
how they handle being launched in this way, specifically path-related
issues.

Although I agree that we should try to aim for as general as possible,
shouldn't we start by getting winGRASS working nicely with msys as a
requirement and then slowly work away from that ? Or do you fear that this
will make us too lazy and not solve the real issues from the start ?

Exactly. Have seen that happening loads of times before and thought I'd avoid it and leave it until we can do things in a more general way! I hate "half-fixing" solutions as it often requires more work later on to undo the half-fix before putting in the "full fix", resulting in user inconvenience that something which used to work now doesn't or has to be done in a different way etc...

Paul

9

Hi all,

as some of you will know, I am keen on pushing GRASS as the GIS of
choice for serious data analysis in my discipline, which is archaeology.
To this end, I have written a number of specific extension, that are of
special value for archaeologists, but may also be applied to other
fields (e.g. predictive modelling).

My colleagues are pretty tired with high prices and lacking
functionality in commercial GIS and if GRASS can be established now, the
potential future benefits for the software and the scientific community
are great. The time is ripe now to claim this field for GRASS!

I can tell you that interest in GRASS (and QGIS) is enormous among
archaeologists, but it will not be possible to establish GRASS unless
there is a version that installs and runs well on Win32.

Now, I have been following the diverse attempts to migrate GRASS to
Win32 -- CygWin, cross compiling, MSYS, etc. -- but I am finally getting
totally confused about where things are heading.

So far, I get the most usable system using the MSYS building environment
provided by the QGIS developers.

HOWEVER, there are two issues that have been sticking around for months
now and prevent me from using the software productively in GIS classes:

1. The DBF driver deadlocks randomly!
Any GRASS module that needs to access the attribute table (DBF format)
of a vector map is prone to this: E.g. I tried running v.out.ogr on a
map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock at
a random point. The task manager shows that v.out.ogr is sleeping with
0% CPU.
Sometimes, I also get random "DBMI protocol errors". The only thing that
helps is to stop and restart the module, hoping that it will finish this
time. Quite annoying. I tested this with several different versions of
QGIS, Windows (XP, 2000) and with different datasets on different PCs:
always the same problem.

Is this the same bug that was/is being discussed under "What is missing"
here: http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status ???
I have replaced the QGIS 0.8.1 rc1 GRASS binaries with Moritz' version,
but the problem persists. If you want to verify this, here is the sample
location I used:

ftp://ftp.rz.uni-kiel.de/pub/ufg/qgis-test.zip

... very simple point data, projection free.

2. There are still issues when QGIS is installed in a path with spaces.
This is a problem with the GRASS modules. I found that at least
g.mremove and d.mon screwed up. There are probably others ...

My problem simply is that I am getting tangled up in the different Win32
migration schemes used by the GRASS and QGIS developers. I would love to
provide Win32 testing feedback and reports for compilation, installation
and usage, but I simply don't know where to start!

Could we please decide on one common approach to supply a stable GRASS
Win32 base that can be shared by both the GRASS and QGIS teams? As far
as I understand, Moritz' system differs in that it supports the Tcl/Tk
stuff? But now there is talk about getting rid of MSYS?

Sorry for the lengthy post and all the complaining but if you could
stand inside my shoes right now, you would see a great chance to claim a
good share of an entire discipline for GRASS GIS. And not being able to
make use of this is pretty frustrating.

Best,

Benjamin

Paul Kelly wrote:

On Mon, 21 May 2007, Moritz Lennert wrote:

I just noticed that the path to the msys shell was not correctly defined,
and that was why they did not execute...duh.

Ah yes you also need the GRASS_SH environment variable set properly,
which I forgot to mention. It should contain the path to the shell
interpreter in Windows path syntax, and is used both by the .bat script
launch mechanism and by g.parser when it "re-launches" each script after
processing the parser options. For that reason it is also used when
WinGRASS is started from Init.sh and it is set both in Init.sh and
init.bat, but if you set it before running them then it won't overridden.

Actually though you need to make sure you have the Msys bin and
MinGW bin and lib directories in your PATH, maybe that's it? That's
something else I've glossed over and should have mentioned, sorry.
Need to
look into that further (Msys documentation perhaps???)

Setting the path variable works great. I now get scripts to actually
work,
using msys' shell tools ! I'll add this to the README of the wingrass
package.

Good to hear. Note it's generally a bad idea (for troubleshooting and
developing) to always have the Msys/MinGW directories in your path as
then you miss some Unixisms in the code such as system("ls") which will
work fine if you have a version of ls in your path.

: I'd originally
hoped that if you started the Msys shell it would insert its needed
directories into the PATH automatically, but that doesn't seem to happen
and I never got round to extending the .bat script-launching system
to do
any path manipulation because, to do that elegantly we need to look at
documentation for other Windows ports of bourne shell interpreters
and see
how they handle being launched in this way, specifically path-related
issues.

Although I agree that we should try to aim for as general as possible,
shouldn't we start by getting winGRASS working nicely with msys as a
requirement and then slowly work away from that ? Or do you fear that
this
will make us too lazy and not solve the real issues from the start ?

Exactly. Have seen that happening loads of times before and thought I'd
avoid it and leave it until we can do things in a more general way! I
hate "half-fixing" solutions as it often requires more work later on to
undo the half-fix before putting in the "full fix", resulting in user
inconvenience that something which used to work now doesn't or has to be
done in a different way etc...

Paul

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

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

10

On 21/05/07 13:58, Benjamin Ducke wrote:

Hi all,

[...]

I can tell you that interest in GRASS (and QGIS) is enormous among
archaeologists, but it will not be possible to establish GRASS unless
there is a version that installs and runs well on Win32.

Now, I have been following the diverse attempts to migrate GRASS to
Win32 -- CygWin, cross compiling, MSYS, etc. -- but I am finally getting
totally confused about where things are heading.

So far, I get the most usable system using the MSYS building environment
provided by the QGIS developers.

How is this more usable then our native builds ? Or are you speaking about using GRASS from within QGIS ?

HOWEVER, there are two issues that have been sticking around for months
now and prevent me from using the software productively in GIS classes:

1. The DBF driver deadlocks randomly!
Any GRASS module that needs to access the attribute table (DBF format)
of a vector map is prone to this: E.g. I tried running v.out.ogr on a
map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock at
a random point. The task manager shows that v.out.ogr is sleeping with
0% CPU.
Sometimes, I also get random "DBMI protocol errors". The only thing that
helps is to stop and restart the module, hoping that it will finish this
time. Quite annoying. I tested this with several different versions of
QGIS, Windows (XP, 2000) and with different datasets on different PCs:
always the same problem.

Is this the same bug that was/is being discussed under "What is missing"
here: http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status ???

No, this issue was solved by compiling xdr as static, instead of shared library. See followups on the same page.

I have replaced the QGIS 0.8.1 rc1 GRASS binaries with Moritz' version,
but the problem persists. If you want to verify this, here is the sample
location I used:

ftp://ftp.rz.uni-kiel.de/pub/ufg/qgis-test.zip

... very simple point data, projection free.

Will try as soon as I can.

2. There are still issues when QGIS is installed in a path with spaces.
This is a problem with the GRASS modules. I found that at least
g.mremove and d.mon screwed up. There are probably others ...

d.mon ? Does that mean you get GRASS monitors working ?

g.mremove is a script which can cause all kinds of shell related problems.

My problem simply is that I am getting tangled up in the different Win32
migration schemes used by the GRASS and QGIS developers. I would love to
provide Win32 testing feedback and reports for compilation, installation
and usage, but I simply don't know where to start!

From a pure GRASS point of view, please test the native builds I post regularly.

Could we please decide on one common approach to supply a stable GRASS
Win32 base that can be shared by both the GRASS and QGIS teams?

I think that this might be good idea, but we have to make sure that we are aiming at the same things.

As far
as I understand, Moritz' system differs in that it supports the Tcl/Tk
stuff?

It supports Tcl/Tk. Don't know if that's the only difference.

But now there is talk about getting rid of MSYS?

You have to differentiate between MinGW/Msys as build environment and Msys as the shell of choice.

At this stage, the idea is to try to aim for a win version of GRASS which is as generic as possible, not imposing the use of one specific shell (e.g. msys), or actually any shell at all.

This means replacing any shell commands used within C-code (e.g. system("ls")) with C-code. Work on this has begun, and Glynn has provided more tools, although some still need to be ported to Windows.

This also means that any shell scripts (e.g. g.mremove, v.dissolve, etc) will either have to be replaced by C-versions (which kind of defeats their purpose of being easily codable for a larger number), be coded in a cross-platform scripting language (e.g. Python), or anyone who wants to use these under Windows has to provide access to a series of shell tools (e.g. through Msys).

Sorry for the lengthy post and all the complaining but if you could
stand inside my shoes right now, you would see a great chance to claim a
good share of an entire discipline for GRASS GIS. And not being able to
make use of this is pretty frustrating.

I am in the same situation as you are (we will migrate all our courses to free software starting next academic year !), so let's try to solve this together as quickly as possible. :slight_smile:

Moritz

11

How is this more usable then our native builds ? Or are you speaking
about using GRASS from within QGIS ?

Sorry, should have been more clear about this: for me the best-working
option for GRASS on Win32 is GRASS + QGIS. I successfully used this to
teach some advanced spatial analysis to GIS novices in the past and was
amazed at how smooth it went.

1. The DBF driver deadlocks randomly!
Any GRASS module that needs to access the attribute table (DBF format)
of a vector map is prone to this: E.g. I tried running v.out.ogr on a
map with ca. 3000 points repeatedly. Out of ten runs, 2 or 3 deadlock at
a random point. The task manager shows that v.out.ogr is sleeping with
0% CPU.
Sometimes, I also get random "DBMI protocol errors". The only thing that
helps is to stop and restart the module, hoping that it will finish this
time. Quite annoying. I tested this with several different versions of
QGIS, Windows (XP, 2000) and with different datasets on different PCs:
always the same problem.

Is this the same bug that was/is being discussed under "What is missing"
here: http://grass.gdf-hannover.de/wiki/WinGRASS_Current_Status ???

No, this issue was solved by compiling xdr as static, instead of shared
library. See followups on the same page.

OK. Too bad. This bug is the single remaining reason for me to delay
putting the software on our institute's pc lab. I tried to find the
cause for this, but eventually got stranded in the DBMI C code without a
good clue.

2. There are still issues when QGIS is installed in a path with spaces.
This is a problem with the GRASS modules. I found that at least
g.mremove and d.mon screwed up. There are probably others ...

d.mon ? Does that mean you get GRASS monitors working ?

No, sorry for causing a fuzz here. All I got was an error message with a
broken path. No idea if it would get any further than that, anyway; but
I thought it was worth mentioning for a future bug fix.

g.mremove is a script which can cause all kinds of shell related problems.

Yep, and we'll have to look into all of them to make sure they can use
these screwed-up Win pathnames, no?

From a pure GRASS point of view, please test the native builds I post
regularly.

OK, so I'll stick with those.

Could we please decide on one common approach to supply a stable GRASS
Win32 base that can be shared by both the GRASS and QGIS teams?

I think that this might be good idea, but we have to make sure that we
are aiming at the same things.

For me, this would be an MSYS environment where I can compile a set of
modules that will work stand-alone or with QGIS. And it looks like this
is possible already, except that the directory layout is a bit different
(everything in the grass-6.3.cvs/lib dir goes into the QGIS install dir,
according to the defaults of the QGIS package). I think what's most
important is that the people who make the QGIS-GRASS packages currently
join in to work in a single compile environment and produce a single set
of binaries.

>
This also means that any shell scripts (e.g. g.mremove, v.dissolve, etc)
will either have to be replaced by C-versions (which kind of defeats
their purpose of being easily codable for a larger number), be coded in
a cross-platform scripting language (e.g. Python), or anyone who wants
to use these under Windows has to provide access to a series of shell
tools (e.g. through Msys).

Well, it would certainly have the positive effect of eliminating the
separate MSYS home dir that Win users have to put up with currently --
that is if all unix shell dependencies can be dropped eventually.

I am in the same situation as you are (we will migrate all our courses
to free software starting next academic year !), so let's try to solve
this together as quickly as possible. :slight_smile:

Great to here, so let's do it!

Moritz

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

12

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Benjamin Ducke ha scritto:

I think what's most
important is that the people who make the QGIS-GRASS packages currently
join in to work in a single compile environment and produce a single set
of binaries.

Agreed: I believe this is extremely important; more generally, the
community will profit a lot from a closer contact between the two
development groups.
pc
- --
Paolo Cavallini
http://www.faunalia.it/pc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGUaLa/NedwLUzIr4RApseAKCbndRswBBazNS22fVwhs5YXU2oSgCfTMUp
0p8NUP7aEw7TZOUerg/vTJ8=
=U3Zn
-----END PGP SIGNATURE-----

13

On 5/21/07 4:58 AM, "Benjamin Ducke" <benjamin.ducke@ufg.uni-kiel.de> wrote:

My problem simply is that I am getting tangled up in the different Win32
migration schemes used by the GRASS and QGIS developers. I would love to
provide Win32 testing feedback and reports for compilation, installation
and usage, but I simply don't know where to start!

Could we please decide on one common approach to supply a stable GRASS
Win32 base that can be shared by both the GRASS and QGIS teams? As far
as I understand, Moritz' system differs in that it supports the Tcl/Tk
stuff? But now there is talk about getting rid of MSYS?

Sorry for the lengthy post and all the complaining but if you could
stand inside my shoes right now, you would see a great chance to claim a
good share of an entire discipline for GRASS GIS. And not being able to
make use of this is pretty frustrating.

Benjamin,

I agree with your assessment about archaeologists being ready to use this,
but that we need to get a Windows version up and running. This is well
underway.

You'll probably get feedback from others, but here is a quick synopsis.

Cygwin is the old, stopgap method to get GRASS running in some way under
windows. However, it is difficult to install, especially on lab machines and
often conflicts with Byzantine Windows security measures. I believe the
Cygwin is being maintained, but not being actively developed.

For the past 6-9 months, Paul Kelley, Moritz Lennart, Glynn Clements and
others have been developing a Windows native version of GRASS--initially
with MinGW (I'm not sure where it is at now from a developer/compiler
standpoint), and using Mysys for script access.

Currently, there is a very usable version that Moritz has kindly made
available as a binary for testing at

http://moritz.homelinux.org/grass/wingrass/

One of my students taught a GRASS short course with an early version of it
last fall. It was a bit rocky at that time, but is much nicer now.

It is a simple zip file and easy to install. Currently, it requires you to
separately install TclTk, and Mysys if you want to use scripts. It needs
testing, but is very actively being worked on. This is the direction for
GRASS for Windows.

I've seen it run and it is very nice. NVIZ is missing, but very recent posts
suggest that this can be going again with minor work.

I hope that this is helpful and encouraging.

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

14

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Barton ha scritto:

It is a simple zip file and easy to install. Currently, it requires you to
separately install TclTk, and Mysys if you want to use scripts. It needs
testing, but is very actively being worked on. This is the direction for
GRASS for Windows.

Soory: whan you say this, what do you exactly mean? We are using the
qgis version, which has of course its limitations, but is very much
usable, and far easier for novices.
I think diversity is a byproduct of freedom, and we have several ways at
hand.
pc
- --
Paolo Cavallini
http://www.faunalia.it/pc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGUcDn/NedwLUzIr4RAmKuAKCU+2CyIoeIv36ZdHnW159b1cYoYACgu2AF
4gs1YeT/HStA6AFrAGMxwZw=
=01rN
-----END PGP SIGNATURE-----

15

This was no comment about QGIS. Just describing the native Windows GRASS
binaries that Moritz has been providing.

Michael

On 5/21/07 8:55 AM, "Paolo Cavallini" <cavallini@faunalia.it> wrote:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Barton ha scritto:

It is a simple zip file and easy to install. Currently, it requires you to
separately install TclTk, and Mysys if you want to use scripts. It needs
testing, but is very actively being worked on. This is the direction for
GRASS for Windows.

Soory: whan you say this, what do you exactly mean? We are using the
qgis version, which has of course its limitations, but is very much
usable, and far easier for novices.
I think diversity is a byproduct of freedom, and we have several ways at
hand.
pc
- --
Paolo Cavallini
Who we are | Faunalia
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGUcDn/NedwLUzIr4RAmKuAKCU+2CyIoeIv36ZdHnW159b1cYoYACgu2AF
4gs1YeT/HStA6AFrAGMxwZw=
=01rN
-----END PGP SIGNATURE-----

__________________________________________
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

16

I think that we can actually make everybody happy here: it should be
possible to have a set of Win32 binaries that support tcl/tk forms (and
in the future wxPython) as well as run with current QGIS.
This way, we can provide several layers of GUI interaction to make the
transition for GIS newbies smooth:

1. QGIS with direct loading of file based geodata
2. the GRASS Toolbox providing a link to GRASS data and a simplified
modules interfaces
3. auto-generated forms on the command line (be they tcl/tk or wxPython)
4. pure command line
5. further tcl/tk and wxPython GUI tools for those that prefer them over
QGIS and its GRASS plugin stuff

... and all in a single Windows installer package!

The most important thing is to have a rock-solid set of binaries for
Win32. And I think we should focus on getting the command line stuff
with MSYS running perfectly first, then we can add GUI dependencies bit
by bit. And later get rid of shell dependencies. At any stage in the
process, there will be a fully usable GRASS on Windows. And everybody
can decide for themselves whether they want to have a package with
tcl/tk, wxpython, MSYS, NVIZ etc. or rather go with QGIS and Paraview.

Let's just forget about Cygwin.

Benjamin

Paolo Cavallini wrote:

Michael Barton ha scritto:

It is a simple zip file and easy to install. Currently, it requires you to
separately install TclTk, and Mysys if you want to use scripts. It needs
testing, but is very actively being worked on. This is the direction for
GRASS for Windows.

Soory: whan you say this, what do you exactly mean? We are using the
qgis version, which has of course its limitations, but is very much
usable, and far easier for novices.
I think diversity is a byproduct of freedom, and we have several ways at
hand.
pc

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

17

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

This seems very sensible. We should keep this approach in parallel on
Linux as well.
pc

Benjamin Ducke ha scritto:

... and all in a single Windows installer package!

The most important thing is to have a rock-solid set of binaries for
Win32. And I think we should focus on getting the command line stuff
with MSYS running perfectly first, then we can add GUI dependencies bit
by bit. And later get rid of shell dependencies. At any stage in the
process, there will be a fully usable GRASS on Windows. And everybody
can decide for themselves whether they want to have a package with
tcl/tk, wxpython, MSYS, NVIZ etc. or rather go with QGIS and Paraview.

Let's just forget about Cygwin.

- --
Paolo Cavallini
http://www.faunalia.it/pc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGUcaK/NedwLUzIr4RAt7PAJwMiI3ZVr0dQs7WfePRbD73MhG5ZwCglQOU
G1mXkIJ9LtRwg/NCRJT7Cs4=
=H5Ey
-----END PGP SIGNATURE-----

18

Benjamin Ducke wrote:

My problem simply is that I am getting tangled up in the different Win32
migration schemes used by the GRASS and QGIS developers. I would love to
provide Win32 testing feedback and reports for compilation, installation
and usage, but I simply don't know where to start!

Could we please decide on one common approach to supply a stable GRASS
Win32 base that can be shared by both the GRASS and QGIS teams? As far
as I understand, Moritz' system differs in that it supports the Tcl/Tk
stuff? But now there is talk about getting rid of MSYS?

Sorry for the lengthy post and all the complaining but if you could
stand inside my shoes right now, you would see a great chance to claim a
good share of an entire discipline for GRASS GIS. And not being able to
make use of this is pretty frustrating.

1. The intent is to support both Cygwin and (native) Windows. Even if
the native version had the same level of functionality as the Cygwin
version, some people will want to use it under Cygwin for other
reasons.

2. With the native version, the intent is that MSys shouldn't be
required to use GRASS, only to build it.

But so long as GRASS includes Bourne-shell scripts, you will need a
compatible shell in order to use those scripts, and MSys is the most
readily available.

Beyond that, if you prefer bash to cmd.exe, then Init.sh will try to
support using it as the session shell. However, MSys' version of bash
uses a virtual Unix-like filesystem which isn't compatible with the
rest of Windows. Also, Windows pathnames aren't compatible with
certain Unix conventions, most notably the fact that search paths
($PATH etc) use a colon as a separator.

Ultimately, getting a "genuinely" native Windows version working takes
precedence. And that means that valid Windows pathnames (e.g.
"C:\path\to\file") need to work everywhere. If that causes problems
for MSys, that's MSys' problem (in the sense that workarounds will
only be accepted if they don't break native usage).

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

19

Moritz Lennert wrote:

This also means that any shell scripts (e.g. g.mremove, v.dissolve, etc)
will either have to be replaced by C-versions (which kind of defeats
their purpose of being easily codable for a larger number), be coded in
a cross-platform scripting language (e.g. Python), or anyone who wants
to use these under Windows has to provide access to a series of shell
tools (e.g. through Msys).

Personally, I would favour switching to Python.

Apart from the portability issues, both Bourne shell and C shell are
*really* poor as general-purpose programming languages.

If you just want to run a sequence of commands, then a shell saves you
the trouble of having to quote the arguments and prefix the command
with an "exec" (or similar) command, as would normally be the case for
a normal programming language.

As soon as you get beyond that, the fact that they were designed as
interactive shells first and programming languages second starts to
become a major problem.

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

20

Michael Barton wrote:

Cygwin is the old, stopgap method to get GRASS running in some way under
windows. However, it is difficult to install, especially on lab machines and
often conflicts with Byzantine Windows security measures. I believe the
Cygwin is being maintained, but not being actively developed.

There's nothing to "develop".

Cygwin is just another Unix platform; if someone reports that
something doesn't work on Cygwin, it will get dealt with in the same
way as a report that something doesn't work on Solaris.

Even if the native Windows version obtains the same level of
functionality as the Unix version, some people may still want to use
the Cygwin version.

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