[Patches] [ python-Patches-590513 ] Add popen2 like functionality to pty.py.

noreply@sourceforge.net noreply@sourceforge.net
Thu, 02 Jan 2003 02:22:51 -0800


Patches item #590513, was opened at 2002-08-04 00:16
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=305470&aid=590513&group_id=5470

Category: Library (Lib)
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: Rasjid Wilcox (rasjidw)
Assigned to: Thomas Wouters (twouters)
Summary: Add popen2 like functionality to pty.py.

Initial Comment:
This patch adds a popen2 like function to pty.py.

Due to use of os.execlp in pty.spawn, it is not quite
the same, as all the arguments (including the command
to be run) must be passed as a tupple.

It is only a first draft, and may need some more work,
which I am willing to do if some direction is indicated.

Tested on Python2.2, under RedHat Linux 7.3.

Rasjid.


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

>Comment By: Rasjid Wilcox (rasjidw)
Date: 2003-01-02 21:22

Message:
Logged In: YES 
user_id=39640

I do plan to do so, but some of Thomas' comments required         
some thought, and in the meantime other priorities came up.   
Also, writing docs and a testcase will take some time (and  
thought) and seem to be the most requrested aspect.   
Realistically, I would expect to get to it within the next month or        
two.  Unfortunately, I can't really promise much more than that. 

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

Comment By: Neal Norwitz (nnorwitz)
Date: 2003-01-02 07:09

Message:
Logged In: YES 
user_id=33168

What is the status of this patch?  Rasjid do still plan to
produce an updated patch.  Note: 2.3 alpha 1 was released
yesterday.

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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-09-10 21:38

Message:
Logged In: YES 
user_id=39640

Thanks for the comments Thomas.
a) I have not done docs or testcase yet.  I wanted to be
clear about the direction first.  I will submit with my next
version.
b) No particular reason for threads, just more intuitive to
me.  On due reflection, os.fork is better.  I shall drop the
use of threads.
c) I shall keep backward compatibility.  Perhaps
'returning_spawn' for the new version.
With luck, next version in a couple of weeks.

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

Comment By: Thomas Wouters (twouters)
Date: 2002-09-09 23:57

Message:
Logged In: YES 
user_id=34209

I have several comments, but I'm not sure if they've been
adressed in other forums or not. Guido mentions
documentation, but the patches attached don't seem to
contain them; are they seperate ? I also don't see a testcase.

 - Why threads ? A seperate non-thread version, with a third
process to handle the data trafficking, and falling back to
that when threads are not available would be nice.

 - I concur the new behaviour is much more useful. However,
I'm a stickler for backward compatibility, so I advice
against renaming the old spawn :)

 - I don't like 'th_spawn'. 'spawn_thread' or
'threaded_spawn' or some such sound better to me (but see
above about threads.)

 - Some minor whitespace issues (the line-wrap on line 150
is not necessary, line 179 is too long, and the backslashes
on lines 190 and 205 are not necessary.) A comment
describing why the tty.setraw() is done would also be nice.


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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-30 13:54

Message:
Logged In: YES 
user_id=39640

Okay.  My final version (I promise!).  The code has been
reorganised a little so that:
a) it is cleaner to read
b) the popen2 function now returns the pid of the child process

Rasjid.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-21 04:33

Message:
Logged In: YES 
user_id=6380

Assigning this to Thomas Wouters according to his wishes.

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

Comment By: Thomas Wouters (twouters)
Date: 2002-08-16 23:47

Message:
Logged In: YES 
user_id=34209

The pty module actually works on all platforms that provide
openpty(). I know at least BSDI and FreeBSD do, in addition
to Linux, and I suspect OpenBSD and NetBSD as well, and
possibly other BSD-derived systems. Still, it is very
unlikely to work on non-POSIX-ish systems, so /bin/sh is a
safe bet.

I can take a look at the patch, and test it on a variety of
machines, but not before I leave on a two-week vacation,
this sunday :) I have plenty of time to look at it when I'm
back though, in the first week of September. Feel free to
assign the patch to me, as a reminder.


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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-16 22:39

Message:
Logged In: YES 
user_id=39640

Okay.  This is essentially my final version, subject to an
issue around the naming of a couple of the modules functions.

My issue is that the pty.spawn funciton does not return.  My
new one 'th_spawn' function does.  I believe quite strongly
that to be consistent with the rest of python, 'th_spawn'
should be renamed 'spawn', and the current spawn function
should be renamed something like '_master' since it takes
the place of the pty master.

The issue of course is backward compatibility.  However, I
believe this to be relatively minor for two reasons.
1.  I think very few (if any) people are using it, since it was
a) largely undocumented,
b) didn't always work
c) wasn't particularly useful, since it only allowed control
from an existing pty (so what was the point?)
2.  If anyone is using it, they would _almost_ certainly be
starting it on a new thread, so all that would happen if the
functions were renamed would be that an extra (redundant)
sub-thread is created.

I have posted to comp.lang.python to see what other pty.py
users think.  Subject to the response here and there, I may
post to python-dev in due course.

Rasjid.

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

Comment By: Guido van Rossum (gvanrossum)
Date: 2002-08-06 01:20

Message:
Logged In: YES 
user_id=6380

I mostly concur with Martin von Loewis's comments, though
I'm not sure this is big enough for a PEP. I think that
you're right in answering (yes, no, yes) but I have no
information (portability of this module is already limited
to IRIX and Linux, according to the docs).

The docs use the word "baffle" -- I wonder if you could
substitute something else or generally clarify that
sentence; it's not very clear from the docs what spawn()
does (nor what fork() does, to tell the truth -- all these
could really use some examples).

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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-05 21:44

Message:
Logged In: YES 
user_id=21627

I'm not a regular pty user. Please ask those questions in
comp.lang.python, and python-dev. You can also ask previous
authors to pty for comments.

Uncertainty in such areas might be a hint that a library PEP
is need, to justify the rationale for all the details.

There is no need to hurry - Python 2.3 is still months away.

That said, I do think that this functionality is desirable,
so I'd encourage you to complete this task.

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

Comment By: Rasjid Wilcox (rasjidw)
Date: 2002-08-05 21:34

Message:
Logged In: YES 
user_id=39640

Before I do docs etc, I have a few questions:

1.  I could make it more popen2 like by changing the args to
def popen2(cmd, ....)  and adding argv=('/bin/sh','-c',cmd)

Is this a better idea?  Does it reduce portability?  Is it
safe to assume that all posix systems have /bin/sh? (My
guess is yes, no and yes.)

2.  Should the threading done in the pty.popen2 function be
moved to a separate function, to allow more direct access to
spawn.  (The current spawn function does not return until
the child exits or the parent closes the pipe).

3.  Should I worry about how keyboard interrupts are
handled?  In some cases an uncontrolled process may be left
hanging around.  Or is it the job of the calling process to
deal with that?

Lastly, I am away for a week from Wednesday, so I won't be
able to do much until I get back, but I will try and finish
this off then.

Cheers,

Rasjid.


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

Comment By: Martin v. Löwis (loewis)
Date: 2002-08-04 18:56

Message:
Logged In: YES 
user_id=21627

Can you please write documentation and a test case?

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

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