[Patches] [ python-Patches-732401 ] Allows os.forkpty to work on more platforms (Solaris!)

SourceForge.net noreply at sourceforge.net
Wed Oct 13 19:46:07 CEST 2004

Patches item #732401, was opened at 2003-05-05 09:20
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting: 

Category: Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 6
Submitted By: Noah Spurrier (noah)
Assigned to: Nobody/Anonymous (nobody)
Summary: Allows os.forkpty to work on more platforms (Solaris!)

Initial Comment:

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.


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

    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!'
    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)


>Comment By: Anthony Baxter (anthonybaxter)
Date: 2004-10-14 03:46

Logged In: YES 

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


Comment By: Noah Spurrier (noah)
Date: 2003-09-04 06:07

Logged In: YES 

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:

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.



Comment By: Martin v. Löwis (loewis)
Date: 2003-07-14 06:27

Logged In: YES 

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.


Comment By: Noah Spurrier (noah)
Date: 2003-07-14 05:52

Logged In: YES 

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.


Comment By: Martin v. Löwis (loewis)
Date: 2003-07-14 01:08

Logged In: YES 

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.


Comment By: Andrew I MacIntyre (aimacintyre)
Date: 2003-07-14 00:06

Logged In: YES 

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? 


You can respond by visiting: 

More information about the Patches mailing list