(moved temporarily here for catching expert answers, then I'll
transfer the result to grass-user to avoid cross-posting)
The point is that the user wants to run without extra hassle
(parameter updates are ok of course) existing G6 scripts in a G7
session on Windows:
------- start fwd -------
On Sat, Apr 30, 2016 at 10:53 AM, Bartolomei.Chris wrote:
> Ok (I guess) but this causes severe problems running shell scripts that call
> out the GRASS modules ... there is no way of knowing which modules are
> compiled executables (which run fine from the shell script) and which ones
> are Windows Batch files (which DON'T run when called from a script) ...
> unless you run the script and figure out which modules make it crash. If you
> look in the bin directory, you'll see a mix of both ... for example r.mask,
> v.build.all and v.db.addcolumn are Windows Batch files which you can''t run
> from a shell script - you have to add the "python {path to
> script}/{script}.py" to run it whereas in the same bin directory v.build,
> v.clean, r.what, etc are compiled executables.
> This is really really (really) bad. There are a lot of legacy shell scripts
> that will need extensive rewriting for which there are no resources to do.
> It's bad enough that msys is gone, the topology is no longer valid (have to
> update all data), a large amount of the module syntax options have changed,
> and so on ... for me all of this grief is because v.net doesn't snap points
> to the network and the fix (in v7) won't be ported to v6.4.4 .... They
> modules should all be compiled executables so legacy shell scripts users have
> can run them ... please make at least ONE thing about this "upgrade"
> semi-straightforward. It's been a nightmare.
------- end fwd -------
I hope someone can give suggestions here.
thanks
Markus
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
