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

[SourceForge.net]

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