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.

Giving to me!

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.

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.

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.

Logged In: YES 
user_id=14198

oops - meant "now that sys.prefix is always set 
correctly." in the last entry.

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).

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.

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 :-)

Logged In: YES 
user_id=14198

I am fairly certain that this bug is correctly fixed.  
test_popen and test_popen2 both now correctly work in 
embedded situations (such as pythonwin) - they always did 
work from python.exe (as python.exe and w9xpopen.exe were 
in the same directory)

Closing (hopefully for good :)