Issue 732401: Allows os.forkpty to work on more platforms (Solaris!) (original) (raw)
Created on 2003-05-04 23:20 by noah, last changed 2022-04-10 16:08 by admin. This issue is now closed.
Messages (10)
Author: Noah Spurrier (noah)
Date: 2003-05-04 23:20
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
# 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)
Author: Andrew I MacIntyre (aimacintyre) * 
Date: 2003-07-13 14:06
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?
Author: Martin v. Löwis (loewis) * 
Date: 2003-07-13 15:08
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.
Author: Noah Spurrier (noah)
Date: 2003-07-13 19:52
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.
Author: Martin v. Löwis (loewis) *
Date: 2003-07-13 20:27
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.
Author: Noah Spurrier (noah)
Date: 2003-09-03 20:07
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
Author: Anthony Baxter (anthonybaxter)
Date: 2004-10-13 17:46
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.
Author: Richard A. Holden III (aciddeath)
Date: 2005-03-22 19:49
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.
Author: Martin v. Löwis (loewis) *
Date: 2005-03-28 18:17
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.
Author: Martin v. Löwis (loewis) *
Date: 2006-07-03 15:24
Logged In: YES user_id=21627
As announced before, I'm now rejecting the patch.