>> But in python eventually stdout.readline() hangs. This is a real
>> nuisance: why can't it just return None?
>
> Because that would be quite annoying because most of the time people want
> blocking behavior.
Just an afterthought: do people prefer the blocking behaviour because
blocking until
pexpect looks promising, thanks.
-- O.L.
--
http://mail.python.org/mailman/listinfo/python-list
>> Yes, that has since occurred to me. I need to echo some magic string
>> after each command to know that I reached the end of the answer to
>> the previous command. In interactive mode the prompt fulfills that
>> role.
>
> And hope that that "magic string" does not occur somewhere within
> the r
> The buffering behavior at the interactive prompt is very often different
> from connections via pipes.
I hadn't thought of that. I will ask on the Octave list.
Thanks,
-- O.L.
--
http://mail.python.org/mailman/listinfo/python-list
On Sun, 27 Jan 2008 19:58:27 +0100, Olivier Lefevre wrote:
>>> But how can I find out *programmatically* that there is no more
>>> input?
>>
>> You can't.
>
> How do people handle this, then? Reading from a process that will
> block if you ask too much yet won't let you know how much there is
>
On Jan 27, 11:08 am, Olivier Lefevre <[EMAIL PROTECTED]> wrote:
> >> Indeed, if I do this interactively, I can tell after 3 lines that I've
> >> gotten all there is to get right now and the fourth readline() call
> >> hangs.
>
> > Can you really?
>
> Yes interactively: at the command prompt, you ca
Olivier Lefevre <[EMAIL PROTECTED]> wrote:
>> Can you really?
> Yes interactively: at the command prompt, you can tell when it's over
> because you know the command you just sent and whether it requires an
> answer and of which kind. Also, even if there is no answer you get a
> fresh prompt when
>> Indeed, if I do this interactively, I can tell after 3 lines that I've
>> gotten all there is to get right now and the fourth readline() call
>> hangs.
>
> Can you really?
Yes interactively: at the command prompt, you can tell when it's over
because you know the command you just sent and whet
> The `trheading` module is modeled after Java's threading API.
OK. Thanks for the hint. However BufferedReader.readline() does
not block in Java, so it is still difficult to transpose.
>> But how can I find out *programmatically* that there is no more
>> input?
>
> You can't.
How do people han
Olivier Lefevre <[EMAIL PROTECTED]> wrote:
>> 1. The subprocess has stopped producing output.
> Indeed, if I do this interactively, I can tell after 3 lines that I've
> gotten all there is to get right now and the fourth readline() call
> hangs.
Can you really? How do you know if the program ha
On Fri, 25 Jan 2008 17:31:16 +0100, Olivier Lefevre wrote:
> Thanks for the answer. Yes this is tricky. I have done it in Java
> before, where you can, e.g., set up a thread to pump stuff out of
> both stderr and stdout continuously but my python is too rudimentary
> for that.
The `trheading` mod
Hi Steve,
Thanks for the answer. Yes this is tricky. I have done it in Java
before, where you can, e.g., set up a thread to pump stuff out of
both stderr and stdout continuously but my python is too rudimentary
for that. There is a key difference anyway: in Java you can write
while (br.readL
Olivier Lefevre wrote:
> I am calling subprocess.Popen with
> p = Popen(args, bufsize=-1, stdin=PIPE, stdout=PIPE, stderr=PIPE)
> and after sending come command to the process, I try to read
> from p.stdout but after a few calls I hang. What is the correct
> way to do this, i.e., to read everything
I am calling subprocess.Popen with
p = Popen(args, bufsize=-1, stdin=PIPE, stdout=PIPE, stderr=PIPE)
and after sending come command to the process, I try to read
from p.stdout but after a few calls I hang. What is the correct
way to do this, i.e., to read everything w/o getting stuck? I am
not fami
14 matches
Mail list logo
