[GRASS-dev] [GRASS-user] why is v.build.all (and many others) a windows batch file and not an executable?

Helmut Kudrnovsky hellik at web.de
Sun May 1 01:15:32 PDT 2016

Markus Neteler wrote
> (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

in the MS windows environment executables are normally identified by file
extensions (e.g. exe, bat, cmd, ...) and can be invoked by typing only the
filename e.g. in a windows console.

there is a limitation of the msys environment that only files with the
exe-extension are recognized as executables.

a simple test in a msys environment with 2 files, which start in a windows
console by typing only the file name:

echo test bat extension in msys

echo test cmd extension in msys

$ cd "C:\tmp\testmsys"

$ ls
mytest.bat  mytest.cmd

$ mytest
sh": mytest: command not found

$ mytest.bat
test bat extension in msys

$ mytest
sh": mytest: command not found

$ mytest.cmd
test cmd extension in msys

and now the same test in a native windows console:

C:\tmp\testmsys>dir /b


C:\tmp\testmsys>echo test bat extension in msys
test bat extension in msys

this clear limitation of the msys environments regarding executable file
extensions was one of the reasons to drop msys in winGRASS.

best regards
View this message in context: http://osgeo-org.1560.x6.nabble.com/Re-GRASS-user-why-is-v-build-all-and-many-others-a-windows-batch-file-and-not-an-executable-tp5263689p5263729.html
Sent from the Grass - Dev mailing list archive at Nabble.com.

More information about the grass-dev mailing list