<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
Thank you all for the comments<br>
<br>
<pre wrap="">>you might want something like Expect.
Yes "Expect" deals with such things, unfortunately it's posix only (due to the PTY module requirement...); whereas I'd like to find generic ways (i.e at least windows/linux/mac recipes)
</pre>
<blockquote cite="mid:pan.2009.06.29.20.45.06.312000@nowhere.com"
type="cite">
<pre wrap="">
The latter is inherently tricky (which is why C's popen() lets you connect
to stdin or stdout but not both). You have to use either multiple threads,
select/poll, or non-blocking I/O.
If the child's output is to the console, it should presumably be the
former, i.e. piping stdin but allowing the child to inherit stdout, in
which case, where's the problem? Or are you piping its stdout via Python
for the hell of it</pre>
</blockquote>
It's well a too-way piping that I'd like to get ; but actually, even a
single-way piping is error-prone : if I try to send data to the child's
stdin, and this child never wants to receive that data (for whatever
reason), the parent thread will be forever stuck. <br>
I can use multiple threads, but it doesn't fully solve the problem,
because having even a single thread stuck might prevent the process
from terminating, on some operating systems... I'd need a way to
deblock I/O blocking threads (but even closing the pipe isn't sure to
do it properly - the closing might be delayed by the I/O operations
wating).<br>
<br>
<br>
>I would guess the architectural differences are so great that an
attempt
<br>
>to "do something simple" is going to involve architecture-specific
code.
<br>
>and I personally wouldn't have it any other way. Simulating a
shell
<br>
>with hooks on its I/O should be so complicated that a "script
kiddie"
<br>
>has trouble writing a Trojan.
<br>
<br>
I'm not sure I understand the security hole there - if a script kiddie
manages to make you execute his program, he doesn't need complex I/O
redirections to harm you, simply destroying files randomly on your hard
drive should fit his needs shouldn't it. :?<br>
<br>
<br>
<blockquote type="cite">
<pre wrap=""><span class="moz-txt-citetags">> </span>I met the issue : select() works only on windows ...
</pre>
</blockquote>
<pre wrap=""><!---->
>No it doesn't. It works only on sockets on Windows, on Unix/Linux it works
>with all file descriptors <a class="moz-txt-link-rfc2396E"
href="http://docs.python.org/library/select.html"><http://docs.python.org/library/select.html></a>.</pre>
<br>
Indeed, I mixed up my words there... >_<<br>
<br>
<br>
>If you are willing to have a wxPython dependency, wx.Execute
handles
non-blocking i/o with processes on all supported platforms
more discussion of python's blocking i/o issues here:<br>
<a class="moz-txt-link-freetext"
href="http://groups.google.com/group/comp.lang.python/browse_thread/thread/a037349e18f99630/60886b8beb55cfbc?q=#60886b8beb55cfbc">>
http://groups.google.com/group/comp.lang.python/browse_thread/thread/a037349e18f99630/60886b8beb55cfbc?q=#60886b8beb55cfbc</a><br>
<br>
Very interesting link, that's exactly the problem... and it seems no
obvious solution comes out of it, except, of course, going down to the
OS' internals...<br>
File support is really weak in python I feel (stdio is a little
outdated...), it'd need a complete blocking/non-blocking,
locking/non-locking stream API straight in the stdlib...<br>
I'm already working on locking classes, I'll explore the opportunity
for a higher level "file" object too whenever possible (a new
filesystem api is in progress here at europython2009, it might be the
occasion).<br>
<br>
<br>
regards,<br>
Pascal<br>
<br>
<div class="moz-txt-sig"><br>
<br>
</div>
</body>
</html>