Hi,
Seems a bit like an edge case with shell scripts on Windows...
Anyway, what about using a script to do the replacement?
Something like (did not test the details):
scripts=$(ls OSGeo4W/apps/grass/grass-7.0.3/scripts/*.py | sed 's/.\{4\}$//')
cp MY_OLD_GRASS_6_SCRIPT.sh MY_NEW_GRASS_7_SCRIPT.sh
for s in $scripts
do
cat MY_NEW_GRASS_7_SCRIPT.sh | sed "s|$s|python
OSGeo4W/apps/grass/grass-7.0.3/scripts/$s.py|g" > MY_NEW_GRASS_7_SCRIPT.sh.tmp
mv MY_NEW_GRASS_7_SCRIPT.sh.tmp MY_NEW_GRASS_7_SCRIPT.sh
done
Cheers
Stefan
-----Original Message-----
From: grass-dev [mailto:[email protected]] On Behalf Of Markus
Neteler
Sent: 30. april 2016 23:32
To: GRASS developers list <[email protected]>
Subject: Re: [GRASS-dev] [GRASS-user] why is v.build.all (and many others) a
windows batch file and not an executable?
(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
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
