exec_command fails if '.exe' not included in filename.

[artegion]

Example (from v.centroids.py):

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

fails with

Traceback (most recent call last):
  File "C:\grass72\GRASS GIS 7.2.svn/scripts/v.centroids.py", line 68, in <module>
    main()
  File "C:\grass72\GRASS GIS 7.2.svn/scripts/v.centroids.py", line 62, in main
    gscript.exec_command("v.category", type='area', **options)
  File "C:\grass72\GRASS GIS 7.2.svn\etc\python\grass\script\core.py", line 553,
 in exec_command
    os.execvpe(prog, args, env)
  File "C:\grass72\GRASS GIS 7.2.svn\Python27\lib\os.py", line 353, in execvpe
    _execvpe(file, args, env)
  File "C:\grass72\GRASS GIS 7.2.svn\Python27\lib\os.py", line 380, in _execvpe
    func(fullname, *argrest)
OSError: [Errno 2] No such file or directory

while modified source

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

works correctly.

It seems like os.execvpe does not use PATHEXT environment variable (maybe because dot in filename overrides PATHEXT and ".category" is taken as file extension)

[glynn]

Replying to artegion:

It seems like os.execvpe does not use PATHEXT environment variable (maybe because dot in filename overrides PATHEXT and ".category" is taken as file extension)

In this specific case, I'd suggest just using run_command() instead of exec_command(). On Windows, they amount to essentially the same thing anyhow; Windows doesn't have a "real" execve(); it just executes the command as a child process, waits for the child to terminate, then exit()s.

There aren't many plausible situations where exec_command() is actually needed; it mostly just provides a very slight efficiency gain (on Unix) by not needing to keep the parent process alive for the duration of the child.

[martinl]

Replying to glynn:

In this specific case, I'd suggest just using run_command() instead of exec_command(). On Windows, they amount to essentially the same thing anyhow; Windows doesn't have a "real" execve(); it just executes the command as a child process, waits for the child to terminate, then exit()s.

done in all active branches (r68954, r68955, r68956). Testing welcome, will be included in the next daily build (1) - so 14/7+.

[neteler]

Was this the only instance of this call?

[martinl]

Replying to neteler:

Was this the only instance of this call?

yes, seems to be.