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