[GRASS-windows] r.report, r.patch

[Glynn Clements]

Helena Mitasova wrote:

> 1. r.report does not work for two students (one has VISTA one has XP)
> it does not print anything - it works for me
> and others - has anybody had a similar problem?

Maybe a problem with writing temporary files?

This (amongst other things[1]) will fail if there are spaces in
$GISDBASE. r.report constructs and executes (with system()) an r.stats
command which redirects to a temporary file, and the temporary
filename isn't quoted.

I've worked around the issue in 7.0 with r33627, which quotes the
filename.

More generally, we need to start eradicating the use of system() in
favour of e.g. G_spawn_ex(). Apart from anything else, this means that
someone needs to do a proper port to Windows using CreateProcess().

[There's currently a half-baked Windows version based around
spawnvpe(), but it doesn't handle redirection. Redirecting to a named
file could be fudged with spawnvpe(), but not redirecting to an open
handle.]

FWIW, I count 41 occurrences of [G_]system and [G_]popen in 7.0.

[1] In the process of converting the scripts to Python, I've noticed
that the output from "v.db.connect -g" isn't suitable for its intended
purpose, as it uses spaces to separate the fields, even though one of
the fields is typically a filename.

> 2. r.patch does not work for one student on VISTA-
> it is exactly the same problem reported as bug #118 but
> according to bug tracker it was fixed and closed
> http://trac.osgeo.org/grass/ticket/118
> The command works for me and others on XP. Is there anybody else
> who still has this problem? Michael did your students get it working?

I think that Windows users will ultimately need to ensure GISDBASE is
within their "Documents" directory. But that will require fixing the
myriad spaces-in-pathnames issues such as the above.

If any non-Windows users want to help out, Unix doesn't prohibit the
use of spaces in pathnames, so you can put a space in the name of the
GISDBASE directory and report any errors you encounter.

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