[GRASS-windows] msys grass63 and wingrass

[Gerald Nelson]

Re the "#!" notation, my 'solution' was just to delete that line. Maybe not
elegant but it did work for me. 

So is the idea to have wingrass either automatically launch a command line
window along with the gui or have an option somewhere in the gui to open the
window, or ... 

And is the idea to include the python code with wingrass or will the user
have to install that separately?

I recall someone posting a message about a link to an intro to python
scripting for grass but a quick browse of oseo.org/grass for
wingrass,python,scripting didn't turn anything up. I have to admit to being
hesitant about learning yet another language. I have a python book on my
shelf from a while ago but didn't get very far into it.

Regards, Jerry

-----Original Message-----
From: Glynn Clements [mailto:glynn at gclements.plus.com] 
Sent: Saturday, February 09, 2008 2:41 PM
To: Gerald Nelson
Cc: grass-windows at lists.osgeo.org
Subject: Re: [GRASS-windows] msys grass63 and wingrass


Gerald Nelson wrote:

> I have had good luck starting wingrass from within an msys terminal and
> using it to run scripts that were originally developed in a linux
> environment. The reason this is helpful is that the scripting features
make
> grass really powerful and as far as I know scripts really only work in
msys.

Bourne shell scripts require MSys (or some other Bourne shell), but
you don't need to start GRASS from MSys.

The main issue with scripts is that Windows doesn't understand the
"#!" notation used to specify the interpreter.

All of the supplied scripts in $GISBASE/scripts have a corresponding
.bat file in $GISBASE/bin which invokes script via %GRASS_SH%. This
allows you to run those scripts from the Windows command prompt.

If you write scripts of your own, you need to either add a
corresponding .bat file, or give the script a .sh extension and
associate that with the shell, e.g. via the ftype and assoc commands. 
You can use the PATHEXT variable to eliminate the need to type the
extension.

> Now if the move to doing scripting in python takes hold, I guess that
would
> remove the need for msys, although it would also mean that a huge number
of
> shell scripts would have to be rewritten.

It would require the scripts to be re-written. However, there are only
75 of them, and most of them are quite straightforward. Someone who is
reasonably familiar with Python (and, specifically, with the
subprocess module), could probably convert most of them in a day.

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