[Python-bugs-list] [ python-Bugs-608635 ] Unix popen does not return exit status

noreply@sourceforge.net noreply@sourceforge.net
Mon, 16 Sep 2002 05:29:29 -0700


Bugs item #608635, was opened at 2002-09-12 22:03
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608635&group_id=5470

Category: Python Library
Group: Python 2.2.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Barry Alan Scott (barry-scott)
Assigned to: Thomas Wouters (twouters)
Summary: Unix popen does not return exit status

Initial Comment:
The documentation for os.popen[234] states that the close
will 
return the rc of the process. This works well on
windows, but the 
unix code does not work, None is
returned.

The 
attached version of popen2.py fixes the problem
by wrapping 
the fromchild fd with an object that
implements the 
documented close() behaviour.

I have also extended the 
test() to cover testing the
rc and run on FreeBSD against 
2.2.1


----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2002-09-16 12:29

Message:
Logged In: YES 
user_id=562624

It seems that Taral has beat me to it. 

http://python.org/sf/608182 "Enhanced file constructor"

This patch would make it possible to implement popen as a 
subclass of file.



----------------------------------------------------------------------

Comment By: Oren Tirosh (orenti)
Date: 2002-09-16 07:41

Message:
Logged In: YES 
user_id=562624

I think I have a cleaner solution than a wrapper object. Now 
that we can inherit from built-in types it should be possible to 
make a subclass of file and override the close method.

There's a small problem because file.__new__ returns an 
uninitialized file object and there is no way to initialize it in 
Python, only from C. I noticed this a while ago but now that I 
see an actual use for subclassing file objects I think it's time to 
fix it.

Patch coming soon.



----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2002-09-13 09:12

Message:
Logged In: YES 
user_id=34209

Hm, for some reason I thought the C 'close()' function (and
os.close()) did return the status. They don't, it should be
'pclose()'. os.popen() passes this as the 'close' function
to the file constructor, so the rest of the statements still
stand :)


----------------------------------------------------------------------

Comment By: Thomas Wouters (twouters)
Date: 2002-09-13 09:03

Message:
Logged In: YES 
user_id=34209

Assigned to me because I'm last in the 'assigned to' select box.

 - Points off because you didn't upload a patch, you
uploaded a new version.   I think I diff'ed against the
right version, but a patch is much better.

 - I'm not happy with the selective copying of attributes to
the wrapper object. For example, you aren't copying
xreadlines -- and what else ? Copying all 'public'
attributes (those not starting with _) seems a much safer bet.

 - The test is wrong; you mean 'exit 6', not 'return 6';
return might work in some shells, but it isn't the correct
way and it doesn't work in bash, at least. I'm also not sure
how portable this is; howmany platforms use the popen2 module ?

 - Why do you a result of convert -1 to None ? -1 seems a
valid return value to me, especially if it's documented as
meaning "process has not finished yet" :)

 - I'm not happy with this solution in general. The problem
lies in Python's handling of the (f)close function (and its
return value) on the fileobject.. os.pipe() returns a fd,
which is turned into a fileobject by os.fdopen -- which
passes 'fclose' as the close method, which always returns 0.
I'd much rather go for a solution where fdopen (or a new
function) handles pipes specially, passing in a fake-fclose
that really does 'close' on the fd (the infrastructure is
all there) or the Popen* classes should just provide a
file-wrapper (or subclass?) altogether, and have the close
method call close on the fd.

But that's just me.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=608635&group_id=5470