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

[Paul Kelly]

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