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

Wed Sep 3 14:07:42 EDT 2003

Patches item #732401, was opened at 2003-05-04 23:20
Message generated for change (Comment added) made by noah
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470

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.

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>

----------------------------------------------------------------------

>Comment By: Noah Spurrier (noah)
Date: 2003-09-03 20:07

Message:
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

----------------------------------------------------------------------

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

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

----------------------------------------------------------------------

Comment By: Noah Spurrier (noah)
Date: 2003-07-13 19:52

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

----------------------------------------------------------------------

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

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

----------------------------------------------------------------------

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

Message:
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? 

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=732401&group_id=5470