[Python-bugs-list] [ python-Bugs-228685 ] popen on Win9x isnt smart enough about finding w9xpopen.exe
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 10 Oct 2001 12:50:53 -0700
Bugs item #228685, was opened at 2001-01-13 11:38
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=228685&group_id=5470
Category: Extension Modules
Group: Platform-specific
Status: Open
Resolution: Fixed
Priority: 5
Submitted By: Mark Hammond (mhammond)
Assigned to: Mark Hammond (mhammond)
Summary: popen on Win9x isnt smart enough about finding w9xpopen.exe
Initial Comment:
The code in posixmodule that emulates popen*() isnt very smart about locating the .exe for the Win9x popen hacks. It assumes that w9xpopen.exe can be located in the directory of the main executable, which fails in may embedding situations.
A reasonable fix would be to also attempt to locate the file in the "sys.prefix" directory - typically this will be set correctly.
Im not at my main dev machine, hence I am submitting a bug rather than a patch. I will submit a patch ASAP.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2001-10-10 12:50
Message:
Logged In: NO
I discovered something related to this bug yesterday, while
experimenting with popen using ActivePython 2.1.1.212 on a
Win98SE box.
The test code was this (I'm new to python, please forgive
any silly things you can find in it :-))
from os import popen2
def getoutput(cmd):
i,o=popen2(cmd)
result=[]
l=o.readline()
while l:
result.append(l)
l=o.readline()
return "\n".join(result)
o.close()
i.close()
If I start python from a directory other than install dir
(e:\python21\ on my box) then:
- the test code hangs on "l=o.readline"
- A short sound is played when the code is run
- a w9xpopen task is shown in task list, after I quit the
hanged python using CTRL-BREAK
- the system hangs after trying to run test code several
times (5 to 7)
If I start python from its install dir, everything works
fine.
It must be noted that if I start python from its install
dir, run the test code, quit python, change the working
dir, restart python and run test code, then it works fine.
Looks like w9xpopen remains in memory even if python is
quit and then restarted from a different dir: well, I don't
think it really stays in memory, but it looks like it stays
there :-)
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2001-09-11 15:41
Message:
Logged In: YES
user_id=14198
You will see the problem if w9xpopen.exe can not be found
either in:
* the directory of the executable
* the sys.prefix directory.
In a build environment, you will have problems if you run
an executable from *outside* the pcbuild directory (eg
pythonwin.exe, or a copy of python.exe copied elsewhere)
In a pre-installed Python, this scenario ('external' .exe)
should work correctly.
----------------------------------------------------------------------
Comment By: Tim Peters (tim_one)
Date: 2001-09-11 09:22
Message:
Logged In: YES
user_id=31435
Mark, I haven't noticed any differences in the behavior of
test_popen2 on Win98SE, whether from an installed Python or
from PCBuild. Did you expect something to break in the
latter case? It doesn't for me. You can test it yourself
on Win2K by setting COMSPEC to point to command.com (in
which case a recent patch makes Python use w9xpopen.exe
even on NT/2000).
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2001-09-11 05:37
Message:
Logged In: YES
user_id=14198
oops - meant "now that sys.prefix is always set
correctly." in the last entry.
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2001-09-11 05:26
Message:
Logged In: YES
user_id=14198
I consider this bug fixed, now that sys.path is always set
correctly. Code already in the popen() implementation will
attempt to locate w9xopen.exe in sys.prefix, which will be
correct in all "installed" Pythons.
Note that this does not work in a build python - sys.prefix
points to the top-level Python source directory, while the
executables are in ".\pcbuild". I don't care enough to fix
this, as I never test on win9x, and it can't bother Tim too
much as he would have just screamed louder before now.
Leaving open until I test some more on a on installed
versions on my w98 box.
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2001-09-11 05:25
Message:
Logged In: YES
user_id=14198
I consider this bug fixed, now that sys.path is always set
correctly. Code already in the popen() implementation will
attempt to locate w9xopen.exe in sys.prefix, which will be
correct in all "installed" Pythons.
Note that this does not work in a build python - sys.prefix
points to the top-level Python source directory, while the
executables are in ".\pcbuild". I don't care enough to fix
this, as I never test on win9x, and it can't bother Tim too
much as he would have just screamed louder before now.
Leaving open until I test some more on a on installed
versions on my w98 box.
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2001-01-30 23:32
Message:
Partial fix checked in Rev 2.183 of Modules/posixmodule.c
As per the comments in that checkin, the code now tries sys.prefix, but in many embedded situations this is still NULL/empty. As soon as source-force is accepting new bugs I will close this and open a new one for sys.prefix being empty in some conditions.
----------------------------------------------------------------------
Comment By: Mark Hammond (mhammond)
Date: 2001-01-13 11:39
Message:
Giving to me!
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=105470&aid=228685&group_id=5470