On Mar 30, 6:57 am, Gabriel Genellina wrote:
> Gabriel Genellina yahoo.com.ar> writes:
>
>
>
> > En Sat, 28 Mar 2009 06:03:33 -0300, geoffbache
> jeppesen.com>
> > escribió:
>
> > > Well yes, but the point is surely that the standard output of the
> > > background sleeping process is pointed t
Gabriel Genellina yahoo.com.ar> writes:
> En Sat, 28 Mar 2009 06:03:33 -0300, geoffbache
jeppesen.com>
> escribió:
> >
> > Well yes, but the point is surely that the standard output of the
> > background sleeping process is pointed to a different location? (you
> > can replace the null device
En Sat, 28 Mar 2009 06:03:33 -0300, geoffbache
escribió:
Hi Tim,
If you trace through this:
python -m trace --trace communicate.py
you'll see that it hangs in subprocess in the stdout_thread waiting for
stdout to close.
Thanks for this tip, haven't used this before.
I'm not sure
Hi Tim,
> If you trace through this:
> python -m trace --trace communicate.py
>
> you'll see that it hangs in subprocess in the stdout_thread waiting for
> stdout to close.
>
Thanks for this tip, haven't used this before.
> I'm not sure I expect this to work as you expect. When you open a
geoff.ba...@gmail.com wrote:
>
>The following code behaves differently on Windows and Linux using
>Python 2.5.2. The Linux behaviour is what I expect in both places :)
>Perhaps somebody could help explain this. Or maybe it is a Python bug.
>Or a Windows feature...
>...
>On Windows if I run "communi
Hi all,
The following code behaves differently on Windows and Linux using
Python 2.5.2. The Linux behaviour is what I expect in both places :)
Perhaps somebody could help explain this. Or maybe it is a Python bug.
Or a Windows feature...
communicate.py ---
import subprocess
p = subprocess.P
