grass.exec_command should add .exe where needed

[michikommader]

Using the GUI or CMD-interface I get the following error when running v.centroids:

v.centroids input=in output=out
Traceback (most recent call last):
  File "C:\OSGeo4W\apps\grass\grass-7.0.0svn\scripts\v.centr
oids.py", line 69, in <module>
    main()
  File "C:\OSGeo4W\apps\grass\grass-7.0.0svn\scripts\v.centr
oids.py", line 63, in main
    grass.exec_command("v.category", type = 'area',
**options)
  File "C:\OSGeo4W\apps\grass\grass-7.0.0svn\etc\python\gras
s\script\core.py", line 499, in exec_command
    os.execvpe(prog, args, env)

Peeking into scripts/v.centroids.py at line 63 reveals a call to

grass.exec_command("v.category", type = 'area', **options)

which fixes the error when changed to

grass.exec_command("v.category.exe", type = 'area', **options)

It looks like you have to add a ".exe" in some cases under Windows.

[annakrat]

Any reason why there is exec_command instead of run_command? Using run_command works for me.

[glynn]

Replying to michikommader:

It looks like you have to add a ".exe" in some cases under Windows.

It isn't quite that simple, as it's perfectly valid to "exec" a script.

Unlike the other *_command() functions, exec_command() isn't based upon Popen() objects, but upon os.execvpe().

os.execvpe() will attempt to locate the executable in the directories specified by PATH, but it won't attempt to determine the suffix according to PATHEXT. The only way in which we could determine the suffix is to enumerate over both PATH and PATHEXT until a match is found.

Alternatively, we could just "fake it" on Windows by calling e.g. run_command() then exit()ing as soon as it returns. I'm fairly sure that's what the Windows' execvpe() is doing (on Unix, the exec* functions replace the program for the current process).

[martinl]

v.centroids now using run_command. Nothing in GRASS is using exec_command. Closing, no activity, feel free to reopen if needed.