Atanas Banov wrote: > Jeffrey Schwab wrote: > >>_PyPclose returns the exit status of the popened process (the popenee?), >>or -1 on error. Of course, if the status is supposed to be -1, there's >>some confusion. > > > yes, that's what i thought the root of the problem is. > > >>In the snippet of code below (from Modules/posixmodule.c), result has >>been initialized to the output of fclose, which in your case is 0. The >>comment is particularly handy. >> > > .... > >> /* Indicate failure - this will cause the file object >> * to raise an I/O error and translate the last >> * error code from errno. We do have a problem with >> * last errors that overlap the normal errno table, >> * but that's a consistent problem with the file object. >> */ > > > the piece you quoted is from the unix #ifdef part, i think. there is > another version of the pypclose for windows below that. > > in any event i think such behaviour is a bug - just because in unix > exit codes are limited to 0..255 (and returned multiplied by 256) > doesnt mean other OSes should suffer because of design flow in > _PyPclose, right? > > throwing an IOError "no error" doesnt help. > > is there a bug database for python where i can check if this was > discussed?
Yes, there's a bug database linked from python.org; search the main page for "Bugs". Here's the most (seemingly) relevant bug report I can find: http://sourceforge.net/tracker/index.php?func=detail&aid=602245&group_id=5470&atid=105470 -- http://mail.python.org/mailman/listinfo/python-list
