eryksun added the comment:
The issue as I understand it is that, on this particular Windows 8.1 system,
passing a non-NULL lpEnvironment to CreateProcess works when starting a native
64-bit executable, but fails when starting a 32-bit executable via the WOW64
system. The child process instead gets an empty environment block.
As an additional check, run the following command in 64-bit cmd.exe:
start "" /I "%SystemRoot%\SysWOW64\cmd.exe"
The /I option of the start command passes the shell's original environment to
CreateProcess, so it should exhibit the same empty-environment problem when
starting 32-bit cmd.exe. In this case you'll get cmd's default environment,
which includes COMSPEC, PATHEXT, and PROMPT.
Since inheriting the current environment works in all cases and passing a
custom environment works for 64-bit executables, the workaround that I
suggested is to use shell=True to pass your custom environment to the shell.
The 32-bit executable thus inherits the custom environment from the shell. If
using shell=True is a security concern, then you can replace it with a Python
script that executes and waits for the child process.
> when passing shell=True everything worked - except
> when passing `cwd` as well, then it's broken again.
Since the shell executes the file, a relative path is resolved against the
shell's working directory. If you set the latter via the cwd parameter, then
pass the file's path as either relative to the cwd path or as a fully qualified
path.
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue24493>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
