[GRASS-dev] porting r.in.wms to python

[Paul Kelly]

On Mon, 6 Oct 2008, Glynn Clements wrote:

> Oops. It turns out that Python doesn't understand %PATHEXT% (but it
> least it's consistent; it doesn't work with .bat or .cmd files
> either).

It looks to me like it doesn't work with .exe either, i.e. it doesn't 
assume the extension - e.g. trying to run a script on Windows I had to 
change line 139 of grass.py from
     os.execvp("g.parser", [name] + argv)
to
     os.execvp("g.parser.exe", [name] + argv)
to get it to do anything at all.

>
> It appears that %PATHEXT%, assoc and ftype are features of cmd.exe.
> CreateProcess() itself doesn't understand them:
>
> 	To run a batch file, you must start the command interpreter;
> 	set lpApplicationName to cmd.exe and set lpCommandLine to the
> 	following arguments: /c plus the name of the batch file.
>
> [ http://msdn.microsoft.com/en-us/library/ms682425.aspx ]
>
> It works if you use os.system(), or subprocess.Popen() with
> shell=True, which isn't surprising. But none of the os.spawn* or
> os.exec* functions work, nor subprocess.Popen() with shell=False.
>
> Having said that, it should be simple enough to create a wrapper
> around the Windows version of subprocess.Popen._execute_child() which
> searches for the "executable" using PATH and PATHEXT, then
> automatically prepends the interpreter where necessary. Or which uses
> subprocess.list2cmdline() to convert the command to a string, then use
> ['cmd', '/c', cmdstring].

Looks like something like that will be necessary.

> In any case, it appears that windows_launch.bat isn't an option, as we
> would need to jump through the same hoops to be able to run .bat files
> directly.

It's neat though in the sense that no registry editing is necessary to 
launch scripts that way, and it will work from the command-line.

>> On the other hand, for the PATHEXT method to work does Python have to be
>> officially "installed" on Windows in some manner? If it does that might
>> preclude just including the Python interpreter as part of a GRASS binary
>> distribution, which someone might want to do.
>
> Also, in order to be able to execute a file without explicitly
> specifying the interpreter, the extension and type have to be known to
> "assoc" and "ftype". AFAICT, the "assoc" information is stored in:
>
>       HKEY_LOCAL_MACHINE\SOFTWARE\Classes\.py
>
> while the "ftype" information is stored in:
>
>       HKEY_LOCAL_MACHINE\SOFTWARE\Classes\python.file\Shell\Open\Command
>
> At least, deleting those keys causes assoc and ftype to immediately
> "forget" the association.
>
> However, these keys weren't set by the Python installer, although it
> did set the keys under both HKEY_CURRENT_USER\Software\Classes and
> HKEY_CLASSES_ROOT. AFAIK, those are the ones which Explorer uses.
>
> If we want to handle this ourselves from within GRASS' Python scripts,
> we can use the _winreg module (note: leading underscore), e.g.:
>
>       >>> import _winreg
>       >>> h = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, 
r'SOFTWARE\Classes\$
>       >>> (val, type) = _winreg.QueryValueEx(h, None)
>       >>> print (val, type)
>       (u'python.file', 1)
>       >>> h = _winreg.OpenKey(_winreg.HKEY_LOCAL_MACHINE, 
r'SOFTWARE\Classes\$
>       >>> (val, type) = _winreg.QueryValueEx(h, None)
>       >>> print (val, type)
>       (u'"C:\\Program Files\\Python25\\python.exe" "%1"', 2)

This seems more complicated than a solution analogous to 
windows_launch.bat with a GRASS_PYTHON environment variable. I'm not sure 
what's best.

Paul