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

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.

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?

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

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!

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

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

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.

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.