> > C:\>1.py
> > hStdOut: 0007
> > Something
> >
> > C:\>1.py>1.txt
> > hStdOut: 0004
> >
> > (1.txt file is now completely empty, i.e. hStdOut is invalid)
>
> Hmm, now I see that maybe that's where I was wrong. When I used
> `python 1.py>1.txt' it suddenly started
> C:\>1.py
> hStdOut: 0007
> Something
>
> C:\>1.py>1.txt
> hStdOut: 0004
>
> (1.txt file is now completely empty, i.e. hStdOut is invalid)
Hmm, now I see that maybe that's where I was wrong. When I used
`python 1.py>1.txt' it suddenly started working as expected. :
On 8/23/07, Mark Hammond <[EMAIL PROTECTED]> wrote:
> > Further investigations showed that it seems to be some strange OS
> > quirk/bug,
> I'm not quite with you here - what strange OS bug do you think you have
> found? I expect that such a bug would be well documented somewhere, even if
> not dir
> Now I finally found that my problem are these two lines in
> subprocess.py:
>
> if stdin is None and stdout is None and stderr is None:
> return (None, None, None, None, None, None)
>
> These lines add an interesting quirk: if I explicitly specify any
> singl
For a long time I was surprised why if I have a script testme.py:
import subprocess
subprocess.call("echo Something", shell=True)
and I try to execute it like this:
python testme.py >testme.txt
I get the output:
The handle is invalid.
Strange failures randomly happened with di
