En Tue, 06 Oct 2009 11:24:23 -0300, MRAB <pyt...@mrabarnett.plus.com>
escribió:
Gabriel Genellina wrote:
En Sat, 03 Oct 2009 21:53:12 -0300, Andrew Savige
<ajsav...@yahoo.com.au> escribió:
When I run this little test program on Linux:
import subprocess
subprocess.call(["python","-V"], stderr=open("log.tmp","a"))
the file log.tmp is appended to each time I run it.
When I run it on Windows, however, the file log.tmp gets
overwritten each time I run it.
Though I can make it append on Windows like this:
import os
import subprocess
f = open("log.tmp", "a")
f.seek(0, os.SEEK_END)
subprocess.call(["python","-V"], stderr=f)
I don't understand why that should be necessary.
Is this a Python/subprocess bug on Windows?
No, it's an "implementation-defined behavior" of the underlying C
library.
That's strange: whenever I've opened a file for append in Microsoft
Visual C/C++ (or Python or Delphi, for that matter) on Windows I've
assumed that the file pointer would be at the end of file, and that's
always proved to be the case!
Yes, true, I've used a small test program in C and that's indeed the case
-- forget the "implementation-defined behavior", in any case, it works the
same way on both platforms.
There is no problem from inside the same process. And the second example
above shows that the file pointer *is* inherited by the child process when
explicitely set. After experimenting a bit, looks like the file pointer is
always at 0 right after opening the file, even for "a" or "a+" modes; it
is moved at the end-of-file before every write.
I guess, on Windows, the file mode isn't properly recreated on the child
process, defaulting to "w" for stdout or something like that. This may be
a bug in the way the subprocess module handles its file arguments (I can
see that subprocess calls functions like _get_osfhandle and
DuplicateHandle, and maybe the original file mode is lost after all those
operations).
--
Gabriel Genellina
--
http://mail.python.org/mailman/listinfo/python-list
