> Can this really be made safe without an explicit flow control protocol,
> such as a pseudo-TTY? stdio reads data from pipes such as stdin in 4K
> or so chunks.
I don't think the subprocess module uses stdio.
> I can easily imagine the child blocking while it waits
> for its stdin buffer to fil
Andrew Bennetts wrote:
> Daniel Stutzbach wrote:
> [...]
>> If you really need to communicate with multiple subprocesses (which so far
>> has
>> not been suggested as a motivating example), then you can use select().
>
> Not portably. select() on windows only works on sockets.
In addition, sele
Daniel Stutzbach wrote:
[...]
>
> If you really need to communicate with multiple subprocesses (which so far has
> not been suggested as a motivating example), then you can use select().
Not portably. select() on windows only works on sockets.
-Andrew.
_
On Mon, Jan 26, 2009 at 4:43 PM, Nick Coghlan wrote:
> With the vanilla subprocess Popen implmentation, the stdin.write calls
> can actually both block if the stdin buffer is full (waiting for the
> child process to clear space) and the stdout.readline call can
> definitely block (waiting for the
Daniel Stutzbach wrote:
> I'm confused. What's wrong with the following?
>
> p = Popen('do_something', stdin=PIPE, stdout=PIPE)
> p.stdin.write('la la la\n')
> p.stdin.flush()
> line = p.stdout.readline()
> p.stdin.write(process(line))
> p.stdin.flush()
>
> If you want t
On Mon, Jan 26, 2009 at 12:44 AM, anatoly techtonik wrote:
> You can't launch a process and communicate with it without blocking at
> some point. The scenario where you can periodically check output and
> error pipes without blocking and send input is not supported.
>
> Scenario One: control conso
I'm confused. What's wrong with the following?
p = Popen('do_something', stdin=PIPE, stdout=PIPE)
p.stdin.write('la la la\n')
p.stdin.flush()
line = p.stdout.readline()
p.stdin.write(process(line))
p.stdin.flush()
If you want to see if data is available on p.stdout, use t
Nick Craig-Wood wrote:
But for the conversational case (eg using it to do a remote login) it
doesn't work at all :-
run child
send stuff to stdin
child reads stdin and writes stdout
Can this really be made safe without an explicit flow control protocol,
such as a pseudo-TTY? stdio read
On Sat, Jan 24, 2009 at 07:58:40AM -0800, Guido van Rossum wrote:
> I'm confused. The subprocess already allows reading/writing its
> stdin/stdout/stderr, and AFAIK it's a platform-neutral API. I'm sure
> there's something missing, but your post doesn't make it clear what
> exactly, and the recipe
Hi, Guido
You can't launch a process and communicate with it without blocking at
some point. The scenario where you can periodically check output and
error pipes without blocking and send input is not supported.
Scenario One: control console program. This implies reading from input
and writing re
Anatoly,
I'm confused. The subprocess already allows reading/writing its
stdin/stdout/stderr, and AFAIK it's a platform-neutral API. I'm sure
there's something missing, but your post doesn't make it clear what
exactly, and the recipe you reference is too large to digest easily.
Can you explain wha
Greetings,
This turned out to be a rather long post that in short can be summarized as:
"please-please-please, include asynchronous process communication in
subprocess module and do not allow "available only on ..."
functionality", because it hurts the brain".
Code to speak for itself: http://cod
12 matches
Mail list logo
