[GRASS-user] Re: CYGWIN

[Glynn Clements]

Luigi Ponti wrote:

> >> But when I do /db.test test1/ errors arise:
> >>     
> >
> >   
> > [...]
> >
> > My guess is that this is a problem with Cygwin and Windows 7.
> >   
> 
> I have eventually reverted back to GRASS 6.3.0 for now, after fixing 
> some missing dll's. I am not sure what is wrong with 6.4 vs 6.3 but I 
> need a functional GRASS/Cygwin version to run some bash scripts while I 
> port them to Phython.

I wouldn't consider the supplied db.test test case failing to equate
to "non-functional"; it's the test case which is wrong, not db.select.

The function which db.select uses to convert a floating-point number
to a string originally used "%f" (which provides 6 decimal places),
was changed to "%.14f" (14 decimal places) then to "%.15g" (15
significant digits, with trailing zeros suppressed). This change had
already been made when 6.4.0-RC5 was released, but the test case
(scripts/db.test/test1) hadn't been updated. The test case has since
been fixed in all current branches.

If you care about the exact format of floating-point values output
from db.select, note that future versions will behave like 6.4.0-RC5,
not like 6.3.x.

> Also, is it even possible to do Python scripting in the native Windows 
> GRASS 6.4.x?

Yes.

> For example, I noticed that some of the GRASS scripts that 
> have been translated to Python require a grass.py package, which I don't 
> see in my osgeo4w installation.

There is no grass.py. It existed for a brief time, but the "grass"
module was replaced with a "grass" package containing multiple
modules, then later split into two subpackages, "script" and "lib".

The change was made to accomodate the SWIG bindings for the GRASS
libraries in the "grass.lib" package, so the scripting functions were
moved from "grass" to "grass.script".

Some early scripts use "import grass", but for current versions
(including 6.4.0-RC5), you need e.g. "import grass.script as grass".

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