[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[Eryk Sun]

Change by Eryk Sun :


--
resolution:  -> third party
stage:  -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[Florian Bruhin]

Florian Bruhin added the comment:

I just ran into this again - when trying to run `git` via subprocess with "env" 
set, I got:

# Start the process
try:
hp, ht, pid, tid = _winapi.CreateProcess(executable, args,
 # no special security
 None, None,
 int(not close_fds),
 creationflags,
 env,
 cwd,
>startupinfo)
EFileNotFoundError: [WinError 2] The system 
cannot find the file specified

This only seems to happen when starting my Python process in cmd.exe, not when 
it's started via my buildbot (CI).

Again, when passing shell=True everything worked - except when passing `cwd` as 
well, then it's broken again.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[Florian Bruhin]

Florian Bruhin added the comment:

> Sounds like there's something in the cwd that is making the difference (this 
> being Windows which looks for things in the cwd always).

The cwd is an empty temporary directory. And that still wouldn't explain why 
passing env=os.environ breaks it as well, and why it only breaks in cmd.exe, 
and only when launching a 32bit process ;)

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[R. David Murray]

R. David Murray added the comment:

Sounds like there's something in the cwd that is making the difference (this 
being Windows which looks for things in the cwd always).

--
nosy: +r.david.murray

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[eryksun]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[Florian Bruhin]

Florian Bruhin added the comment:

I've now updated to Python 3.4.3 and it's broken there as well.

I tried on two other Windows 8.1 machines (with Python 3.4.3 and 3.4.1 
respectively), and I can't reproduce there either...

It works with shell=True indeed.

I wonder why this is only broken on that one machine... It's a virtual machine 
which only has Firefox, Python, PyQt and a few Python packages installed - 
otherwise it's vanilla.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24493
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[eryksun]

eryksun added the comment:

 It seems only a minimal set of environment variables are set 

Apparently the initial environment is empty. The values you see are defaults 
set by cmd.exe when it starts. It also sets the 'hidden' variable =C: to the 
current directory on the C: drive, which you can see via set . 

As a workaround, try running the command using shell=True (i.e. cmd /c). This 
should let you modify the environment passed to 64-bit cmd.exe, which will be 
inherited by the grandchild process that it creates.

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24493
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24493] subprocess with env=os.environ doesn't preserve environment variables when calling a 32bit process on Windows 8.1

[Florian Bruhin]

Florian Bruhin added the comment:

Sorry I missed this - I can reproduce this on Windows 8.1, but not on Windows 
7. I hope I'll be able to try another Windows 8.1 machine today.

SYSTEMROOT is definitely set in the original environment:

 os.environ['SYSTEMROOT']
'C:\\Windows'
 subprocess.call('{} /c set SYSTEMROOT'.format(cmd32), env=os.environ)
Environment variable SYSTEMROOT not defined
1
 subprocess.call('{} /c set SYSTEMROOT'.format(cmd32))
SystemRoot=C:\Windows
0

It seems only a minimal set of environment variables are set in the spawned 
process:

 subprocess.call('{} /c set'.format(cmd32), env=os.environ)
COMSPEC=C:\Windows\SysWOW64\cmd.exe
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.JS;.WS;.MSC
PROMPT=$P$G

--
title: subprocess with env=os.environ fails with fatal python error when 
calling 32-bit python from 64-bit one on Windows - subprocess with 
env=os.environ doesn't preserve environment variables when calling a 32bit 
process on Windows 8.1

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24493
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com