[GRASS-dev] Re: writing msys capable grass63 startup script

Moritz Lennert mlennert at club.worldonline.be
Sun May 20 18:24:15 EDT 2007

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.


More information about the grass-dev mailing list