[Python-bugs-list] [ python-Bugs-228685 ] popen on Win9x isnt smart enough about finding w9xpopen.exe

[noreply@sourceforge.net]

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