| msg54176 - (view) |
Author: A.M. Kuchling (akuchling) *  |
Date: 2004-06-05 16:29 |
| (Originally suggested by James Henstridge in bug #897935) There are also a few changes that would be nice to see in pty.spawn: 1) get the exit status of the child. Could be fixed by adding the following to the end of the function: pid, status = os.waitpid(pid, 0) return status 2) set master_fd to non-blocking mode, so that the output is printed to the screen at the speed it is produced by the child. |
|
|
| msg54177 - (view) |
Author: James Henstridge (jamesh) |
Date: 2004-06-09 14:16 |
| Logged In: YES user_id=146903 Since filing the original bug report, I got reports that simply setting the fds to non-blocking caused problems under Solaris. Some details are available in this bug report: http://bugzilla.gnome.org/show_bug.cgi?id=139168 The _copy() function never raised an IOError or OSError, so it never exited. I'd imagine that EOF could be detected by getting back then empty string when reading from the fd when select() says it is ready for reading, but I haven't checked whether this works. |
|
|
| msg54178 - (view) |
Author: Neal Norwitz (nnorwitz) * |
Date: 2007-03-16 06:08 |
| Wouldn't it be better to just return the pid. The caller can get the status if they want or do anything else with the pid. I'm guessing #2 is no longer requested? |
|
|
| msg54179 - (view) |
Author: James Henstridge (jamesh) |
Date: 2007-03-20 06:32 |
| #2 was an old misunderstanding by me about file.read() vs. os.read() w.r.t pipes, so is not needed. As for returning the status code vs the pid, it looks like spawn() is designed to return only when it can't read/write to the subprocess. You could return the pid at this point, but the process has most likely finished running at this point so the only thing you'd be likely to do is call waitpid() on it (and it is necessary to call waitpid() for the child process to be cleaned up properly). That's why I suggested that pty.spawn() get the child status itself. |
|
|
| msg66864 - (view) |
Author: Petr Splichal (psss) |
Date: 2008-05-15 15:02 |
| Is there any plan to modify pty.spawn() so that it reports child's status? I think this would be really a very useful feature. Thanx! |
|
|
| msg88669 - (view) |
Author: Fergus Henderson (fergushenderson) |
Date: 2009-06-01 20:05 |
| #1 is a duplicate of issue 2489 <http://bugs.python.org/issue2489>, which has a patch attached. According to the other discussion in this thread, #2 was a misunderstanding. So I think we could close this bug as a duplicate. |
|
|
| msg115124 - (view) |
Author: R. David Murray (r.david.murray) * |
Date: 2010-08-27 19:49 |
| No, issue 2489 is a bug fix, and the inclusion of a feature request in it has already had an objection. This bug should stay open to cover the feature request, I think. The patch for the RFE is pretty simple... |
|
|
| msg190049 - (view) |
Author: Mark Lawrence (BreamoreBoy) * |
Date: 2013-05-26 02:56 |
| So #2489 broke at least one buildbot and this has to stay open for an enhancement request. Frankly it all confuses the hell out of me, could someone please explain in words of one syllable or less, thanks. |
|
|
| msg190082 - (view) |
Author: A.M. Kuchling (akuchling) * |
Date: 2013-05-26 12:28 |
| It looks like the problem on OpenIndiana with #2489 was fixed. As of May 25th, the 3.x build on OpenIndiana is a green. http://buildbot.python.org/all/builders/x86%20OpenIndiana%203.x/builds/5962 So, 2) is a misunderstanding and 1) was carried out in #2489 (despite any objections to putting a feature enhancement in a bugfix, the feature is still there in trunk). Therefore, I'm going to close this bug because there's nothing to do. |
|
|