Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

popen3 on windows loses environment variables #41436

Closed
juneaftn mannequin opened this issue Jan 13, 2005 · 6 comments
Closed

popen3 on windows loses environment variables #41436

juneaftn mannequin opened this issue Jan 13, 2005 · 6 comments
Labels
stdlib Python modules in the Lib dir

Comments

@juneaftn
Copy link
Mannequin

juneaftn mannequin commented Jan 13, 2005

BPO 1101667
Nosy @birkenfeld

Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-07-30.11:40:07.000>
created_at = <Date 2005-01-13.14:33:05.000>
labels = ['library']
title = 'popen3 on windows loses environment variables'
updated_at = <Date 2006-07-30.11:40:07.000>
user = 'https://bugs.python.org/juneaftn'

bugs.python.org fields:

activity = <Date 2006-07-30.11:40:07.000>
actor = 'georg.brandl'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Library (Lib)']
creation = <Date 2005-01-13.14:33:05.000>
creator = 'juneaftn'
dependencies = []
files = []
hgrepos = []
issue_num = 1101667
keywords = []
message_count = 6.0
messages = ['23950', '23951', '23952', '23953', '23954', '23955']
nosy_count = 3.0
nosy_names = ['georg.brandl', 'juneaftn', 'ompeag']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1101667'
versions = ['Python 2.4']

@juneaftn
Copy link
Mannequin Author

juneaftn mannequin commented Jan 13, 2005

see the following test code:

#test_popen3_1.py
import os
FILENAME='c:\temp\test_popen3_2.py'
os.environ['FOOBAR']='foobar'
print os.environ['FOOBAR']
fs=os.popen3("c:\python24\python -u %s"%
FILENAME,'b')
print fs[1].read()

#c:\temp\test_popen3_2.py
print "from test_popen3_2.py"
import os;print os.environ['FOOBAR']

Running test_popen3_1.py is expected to print out:
foobar
from test_popen3_2.py
foobar

But it doesn't print the last foobar. It correctly prints
out when run on python 2.3.

If the FILENAME is set to a relative path, as when you
are in the c:\temp directory and the FILENAME is set to
test_popen3_2.py, the code works correct.

Tests run on windows XP, SP1.

This bug is related to the cgi bug bpo-1100235.

@juneaftn juneaftn mannequin closed this as completed Jan 13, 2005
@juneaftn juneaftn mannequin added the stdlib Python modules in the Lib dir label Jan 13, 2005
@juneaftn
Copy link
Mannequin Author

juneaftn mannequin commented Jan 13, 2005

Logged In: YES
user_id=116941

Sorry. I got confused. When FILENAME is absolute, popen3
loses the environment variables, whereas it is relative,
popen3 works fine.

@ompeag
Copy link
Mannequin

ompeag mannequin commented Jan 26, 2005

Logged In: YES
user_id=1155133

I've tried recreating this problem and have had no luck. I've
tried three versions of python: 2.3, 2.4, and the current
build version (2.5 something?). I've also tried both absolute
and relative paths. All tests print out the second 'foobar' just
fine. I, too, am running XP, SP1.

Any chance there's something special about how you are
running the executables? Say from a cygwin environment or
something?

@juneaftn
Copy link
Mannequin Author

juneaftn mannequin commented Jan 27, 2005

Logged In: YES
user_id=116941

Oh, stupid me. The full path filename included '\t'. It
should've been escaped. Then the example code works with 2.3
and 2.4.

The real problem seems to be with os.environ.

I have reassured this problem exists on some XP SP1 boxes.

The test code is...

#test_popen3_1.py
import os
FILENAME='test_popen3_2.py'
env={};env['ENVIRON_UPDATE']='123';os.environ.update(env)
os.environ['ENVIRON_DIRECT_SETTING']='123'
cmdline='c:\python24\python.exe -u %s'%FILENAME
fs=os.popen3(cmdline,'b')
print fs[1].read()

#test_popen3_2.py
import os
if os.environ.has_key('ENVIRON_UPDATE'):print 'os.env.update
worked'
else:print 'os.env.update failed'
if os.environ.has_key('ENVIRON_DIRECT_SETTING'):print
'os.env assignment worked'
else:print 'os.env assignment failed'

Put these two files in the same path and run
test_popen3_1.py with python2.4 and python2.3.

Following is the result I got:

C:\test>\python23\python test_popen3_1.py
os.env.update worked
os.env assignment worked

C:\test>\python24\python test_popen3_1.py
os.env.update failed
os.env assignment worked

As you see the environment varaible that's updated with
os.environ.update has failed to get passed to popen3ed process.

This is the reason CGIHTTPServer.py fails to deliver
QUERY_STRING and etc. -- they are updated with
os.environ.update(env).

@juneaftn
Copy link
Mannequin Author

juneaftn mannequin commented Jan 27, 2005

Logged In: YES
user_id=116941

Now I got it. The reason is os.py in python2.4 has changed
so that the _Environ(UserDict.IterableUserDict) has lost its
update method -- there was on in python2.3.

To rectify the problem you just copy and paste the update
method from python2.3 os.py.

--- os.py       Thu Jan 27 07:09:38 2005
+++ os_new.py   Thu Jan 27 07:10:44 2005
@@ -435,6 +435,9 @@
                 return key.upper() in self.data
             def get(self, key, failobj=None):
                 return self.data.get(key.upper(), failobj)
+            def update(self, dict):
+                for k, v in dict.items():
+                    self[k] = v
             def copy(self):
                 return dict(self)

@@ -446,6 +449,9 @@
             def __setitem__(self, key, item):
                 putenv(key, item)
                 self.data[key] = item
+            def update(self, dict):
+                for k, v in dict.items():
+                    self[k] = v
             try:
                 unsetenv
             except NameError:

@birkenfeld
Copy link
Member

Logged In: YES
user_id=849994

This was fixed in rev. 38397.

@ezio-melotti ezio-melotti transferred this issue from another repository Apr 9, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
stdlib Python modules in the Lib dir
Projects
None yet
Development

No branches or pull requests

1 participant