Recent changes to os.openpty() make it much more
portable than earlier versions. Unfortunately,
os.forkpty() was not also upgraded. This patch to
posixpath.c allows os.forkpty() to run on any platform
that supports os.openpty(). 

This new os.forkpty() will use the C system call
forkpty() if available. If not available, then it will
do it the old fashioned way with openpty and fork (and
only if those too are available, otherwise forkpty
remains undefined as before).

Other benefits:

Since the pty module is based on os.forkpty() this
patch will automatically allow pty.fork() to work
properly on more platforms. The pty module does not
need to be changed. The logic for supporting pty's on
multiple platforms can be maintained in one spot
instead of in both the posix_module.c and pty.py

One of the more notable platforms that does not support
the forkpty system call is Solaris. Most importantly to
me, this patch will allow os.forkpty() to be available
under Solaris. I am testing it with my Pexpect module
which makes heavy use of the pty module. With this
patch Pexpect passes all my unit tests on Solaris.
Pexpect has been tested on Linux, OpenBSD, Solaris, and
Cygwin. I'm looking for an OS X server to test with.
The code for forkpty should be quite portable and is
based on the pty code in OpenSSH and the example in
Stevens' "Advanced Programming in the UNIX Environment".

I have included a test script, test_forkpty.py.

Yours,
Noah

<pre>
# Test to see if forkpty works. (But don't worry if it
isn't available.)

import os, time
from test.test_support import verbose, TestFailed,
TestSkipped

try:
    if verbose:
        print 'Calling os.forkpty()'
    pid, fd = os.forkpty()
except AttributeError:
    raise TestSkipped, 'No os.forkpty() available.'

if pid == 0: # child
    print 'I am not a robot!'
else:
    if verbose:
        print '(pid, fd) = (%d, %d)' % (pid, fd)
    time.sleep(1) # Give the child a chance to print.
    print 'Robots always say:', os.read(fd,100)
    os.close(fd)
</pre>

Logged In: YES 
user_id=250749

Martin, I've eyeballed the patch and can't see that it would
have any effect other than to extend the availability of
os.forkpty (assuming that it compiles on all the platforms
that it extends to).

FreeBSD has forkpty(), so I can't test this myself (I
haven't tried to set up a SF compile farm account yet).

I'm a little wary about it being this close to 2.3 release -
is this worth pursuing at this point, or should it be
deferred to post-2.3? 

Logged In: YES 
user_id=21627

It should be deferred. Mere addition of openpty has nearly
made the entire pty handling nearly unusable on some
systems, as the C library versions of these functions tend
to be buggy beyond repair. So I'd rather don't add any more
breakage here.

Logged In: YES 
user_id=59261

Which openpty has made pty handling unusable? 
There are two: os.openpty() and pty.openpty().

What is a good strategy for making pty handling more
consistent? I think it's impossible to make pty handling
totally platform independent, but Python's pty module could 
certainly be cleaned up to hide the ugliness. 
Platforms that are not explicitly handled should probably not 
define forkpty. Currently Solaris uses the wrong code -- 
thus leaving the user with the impression that Solaris is 
supported, but providing a broken implementation.

Pty handling is a headache -- I never understood why it was 
overlooked by POSIX given that ptys are critical to  every 
UNIX system.

Logged In: YES 
user_id=21627

The addition of support for ptmx inside posix.openpty has
caused the test suite to hang on HP-UX and other systems.

A good strategy would be to find some code base, and
rigorously test these on all 8 or so supported Unix
variants. I'm willing to accept any code that has been
tested so, but only after Python 2.3.

Logged In: YES 
user_id=59261

Is there a place where a prospective developer can test
on these 8 platforms?
I read the Developer FAQ and have been going through
the School of Hard Knocks:
http://mail.python.org/pipermail/python-dev/2002-
September/028725.html

I would like to work with someone on this as
I only have access to the platforms on Compile Farm
from SourceForge. The fact that ptmx support causes
HP-UX to hang is probably a simple configuration problem
(perhaps incorrectly defining HAVE_DEV_PTMX), but it's
impossible for me to research this using only the Compile Farm.

Yours,
Noah

Logged In: YES 
user_id=29957

Google for "HP testdrive". DEC^W Digital^W Compaq^W HP have
a farm of test systems you can use for testing.

Logged In: YES 
user_id=591527

Would it be possible to revisit this since we are now on
2.4? I am developing on pexpect and having this would
greatly simplify my life.

Logged In: YES 
user_id=21627

In the absence of a patch that is known to work on all
relevant platforms, there is nothing really to revisit. Most
likely, the next action on this patch is to reject it,
unless somebody steps forward to do the remaining work.

Logged In: YES 
user_id=21627

As announced before, I'm now rejecting the patch.