[GRASS-dev] Re: [GRASS GIS] #783: r.watershed fails on wingrass
GRASS GIS
trac at osgeo.org
Thu Oct 15 00:33:19 EDT 2009
#783: r.watershed fails on wingrass
---------------------------+------------------------------------------------
Reporter: hamish | Owner: grass-dev at lists.osgeo.org
Type: defect | Status: new
Priority: major | Milestone: 6.4.0
Component: Raster | Version: 6.4.0 RCs
Resolution: | Keywords: r.watershed, wingrass
Platform: MSWindows XP | Cpu: x86-32
---------------------------+------------------------------------------------
Comment (by hamish):
Replying to [comment:10 glynn]:
> I suspect that eliminating the quotes will mean that it fails
> if GRASS is installed in a directory which contains spaces,
right.
> and without Administrator privileges you may be unable to
> install GRASS in a directory which doesn't contain spaces.
Can you install to your Windows home dir or desktop anyway?
note that MSys devs do not seem interested in accepting patches which
allow it to work in directories containing spaces, so it may be a long
wait until this is more than an academic issue.
http://sourceforge.net/search/?group_artifact_id=102435&type_of_search=artifact&group_id=2435&words=spaces
Replying to [comment:11 mmetz]:
> (I tried putting flags at the end, they don't get quotes), and
> add their own quotes to the beginning and end (locale-specific,
> double quotes on my German XP version, single quotes on English
> XP version).
IIguessC those added german " and english ' quotes are just for the
formatting of the error message??
> In order to avoid both quotes and spaces, the only alternative I
> could find was adding the path to r.watershed.[ram|seg] to PATH
> or r.watershed.[ram|seg] to something that's in PATH. But
> r.watershed.[ram|seg] is currently not in PATH in order to hide
> them from users IIRC.
>
> Another possibility could be to rewrite r.watershed and put
> r.watershed.[ram|seg] into a local library like e.g. r.li.daemon?
>
> In short, I could not find a way to make it work with quotes on
> windows (BTW, neither osgeo4w nor mingw-w64 with XP 64bit).
the easiest and least invasive solution seems to me to just replace
system("") with G_spawn($0, **list).
Long-term rationalizing of the code is a valid but different matter. Right
now I am concerned with getting a working 6.4.0 out the door with least-
risk. To me the answer to that is to ship it unquoted for 6.4.0 with a
note in the errata page; use G_spawn() in 6.4.1; and refactor the module
in trunk as you see fit.
Hamish
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/783#comment:12>
GRASS GIS <http://grass.osgeo.org>
More information about the grass-dev
mailing list