On suse 9.3, tempfile.NamedTemporaryFile() doesnt work as expected.
(I found a permanent workaround, so I dont ask for help)
I expected to write to a file, and access it thru a shell command.
This code, in a loop:
tf = tempfile.NamedTemporaryFile()
tfName = tf.name
#tf.seek(0) # rewind the file
tf.write(chunk); tf.flush()
print >sys.stderr, '%s: %s' % (tfName, ['no',
'yes'][os.path.exists(tfName)])
subprocess.Popen(['strings', tfName])
Symptom: the file does not always exist, after the call to
NamedTemporaryFile(). Or at least its not seen by the strings command,
or by os.path.exists.
I guess the bug is pretty much os dependent, or even filesystem
dependent (Im on reiserfs). Maybe the os is buggy, maybe, somehow, the
python interface. Or did I miss something?
Shame, I didnt even try to check for a python bug tracker. 6 4549
Imbaud Pierre wrote:
tf = tempfile.NamedTemporaryFile()
tfName = tf.name
[...]
print >sys.stderr, '%s: %s' % (tfName, ['no',
'yes'][os.path.exists(tfName)])
subprocess.Popen(['strings', tfName])
Just out of curiosity: Why did you assign tf.name to tfname?
Hypothetically, if tf.name changed, tfname wouldn't follow since
strings are immutable.
Regards,
Björn
--
BOFH excuse #149:
Dew on the telephone lines.
On Sun, 19 Nov 2006 13:11:13 +0100, Imbaud Pierre wrote:
On suse 9.3, tempfile.NamedTemporaryFile() doesnt work as expected.
[snip]
Symptom: the file does not always exist, after the call to
NamedTemporaryFile(). Or at least its not seen by the strings command,
or by os.path.exists.
I guess the bug is pretty much os dependent, or even filesystem
dependent (Im on reiserfs). Maybe the os is buggy, maybe, somehow, the
python interface. Or did I miss something?
Shame, I didnt even try to check for a python bug tracker.
I can verify this problem occurs on Fedora Core 5 too:
import os
import sys
import tempfile
import subprocess
def test(n):
chunk = ': +++ abcd +++'
for i in xrange(n):
tf = tempfile.NamedTemporaryFile()
tfName = tf.name
tf.seek(0)
tf.write(str(i) + chunk)
tf.flush()
if not os.path.exists(tfName):
print 'pre-check: %s not there' % tfName
subprocess.Popen(['strings', tfName])
if not os.path.exists(tfName):
print 'post-check: %s not there' % tfName
And here is a typical run, with the boring bits removed for ease of
reading:
>>test(30)
0: +++ abcd +++
1: +++ abcd +++
[ more of the same ]
14: +++ abcd +++
strings: '/tmp/tmpOALbx9': No such file
16: +++ abcd +++
17: +++ abcd +++
18: +++ abcd +++
[ more of the same ]
27: +++ abcd +++
strings: /tmp/tmpdc52Nz: No such file or directory
29: +++ abcd +++
Curiouser and curiouser... not only does os.path.exist always report the
temp file as existing (at least in my tests), even when strings can't find
it, but strings returns different error messages.
Is it possible this is a bug in strings?
--
Steven.
On Sun, 19 Nov 2006 13:18:39 +0100, Bjoern Schliessmann wrote:
Imbaud Pierre wrote:
> tf = tempfile.NamedTemporaryFile() tfName = tf.name [...] print >sys.stderr, '%s: %s' % (tfName, ['no', 'yes'][os.path.exists(tfName)]) subprocess.Popen(['strings', tfName])
Just out of curiosity: Why did you assign tf.name to tfname?
Hypothetically, if tf.name changed, tfname wouldn't follow since
strings are immutable.
Well, yes, but if tf.name changed, that won't change the file name on disk
either:
>>tf = tempfile.NamedTemporaryFile() tf.name
'/tmp/tmpYVV1Ij'
>>os.path.exists(tf.name)
True
>>oldname = tf.name tf.name = "/tmp/something" os.path.exists(tf.name)
False
>>os.path.exists(oldname)
True
I'm guessing that binding tf.name to tfName is a micro-optimization. In a
very tight loop, name lookups can take considerable time, and one
optimization can be to reduce the number of lookups:
method = something.method
while 1:
something.method # needs at least two lookups
method # needs a single lookup
--
Steve.
Steven D'Aprano wrote:
On Sun, 19 Nov 2006 13:11:13 +0100, Imbaud Pierre wrote:
>On suse 9.3, tempfile.NamedTemporaryFile() doesnt work as expected.
[snip]
>Symptom: the file does not always exist, after the call to NamedTemporaryFile(). Or at least its not seen by the strings command, or by os.path.exists.
I guess the bug is pretty much os dependent, or even filesystem dependent (Im on reiserfs). Maybe the os is buggy, maybe, somehow, the python interface. Or did I miss something? Shame, I didnt even try to check for a python bug tracker.
I can verify this problem occurs on Fedora Core 5 too:
import os
import sys
import tempfile
import subprocess
def test(n):
chunk = ': +++ abcd +++'
for i in xrange(n):
tf = tempfile.NamedTemporaryFile()
tfName = tf.name
tf.seek(0)
tf.write(str(i) + chunk)
tf.flush()
if not os.path.exists(tfName):
print 'pre-check: %s not there' % tfName
subprocess.Popen(['strings', tfName])
if not os.path.exists(tfName):
print 'post-check: %s not there' % tfName
And here is a typical run, with the boring bits removed for ease of
reading:
>>>test(30)
0: +++ abcd +++
1: +++ abcd +++
[ more of the same ]
14: +++ abcd +++
strings: '/tmp/tmpOALbx9': No such file
16: +++ abcd +++
17: +++ abcd +++
18: +++ abcd +++
[ more of the same ]
27: +++ abcd +++
strings: /tmp/tmpdc52Nz: No such file or directory
29: +++ abcd +++
Curiouser and curiouser... not only does os.path.exist always report the
temp file as existing (at least in my tests), even when strings can't find
it, but strings returns different error messages.
Is it possible this is a bug in strings?
What /you/ are seeing is not a bug, I think. Popen() is asynchronous,
therefore you may enter the second iteration -- which implicitly closes the
temporary file -- before strings actually tries to access it. Use call()
and everything should be fine.
Peter
Steven D'Aprano a écrit :
On Sun, 19 Nov 2006 13:18:39 +0100, Bjoern Schliessmann wrote:
>>Imbaud Pierre wrote:
>> tf = tempfile.NamedTemporaryFile() tfName = tf.name [...] print >sys.stderr, '%s: %s' % (tfName, ['no', 'yes'][os.path.exists(tfName)]) subprocess.Popen(['strings', tfName])
Just out of curiosity: Why did you assign tf.name to tfname?
Hypothetically, if tf.name changed, tfname wouldn't follow since strings are immutable.
Well, yes, but if tf.name changed, that won't change the file name on disk
either:
>>>>tf = tempfile.NamedTemporaryFile() tf.name
'/tmp/tmpYVV1Ij'
>>>>os.path.exists(tf.name)
True
>>>>oldname = tf.name tf.name = "/tmp/something" os.path.exists(tf.name)
False
>>>>os.path.exists(oldname)
True
I'm guessing that binding tf.name to tfName is a micro-optimization.
indeed. And I dont see why tf.name would change.
In a
very tight loop, name lookups can take considerable time, and one
optimization can be to reduce the number of lookups:
method = something.method
while 1:
something.method # needs at least two lookups
method # needs a single lookup
Peter Otten a écrit :
Steven D'Aprano wrote:
>>On Sun, 19 Nov 2006 13:11:13 +0100, Imbaud Pierre wrote:
>>>On suse 9.3, tempfile.NamedTemporaryFile() doesnt work as expected.
[snip]
>>>Symptom: the file does not always exist, after the call to NamedTemporaryFile(). Or at least its not seen by the strings command, or by os.path.exists.
I guess the bug is pretty much os dependent, or even filesystem dependent (Im on reiserfs). Maybe the os is buggy, maybe, somehow, the python interface. Or did I miss something? Shame, I didnt even try to check for a python bug tracker.
I can verify this problem occurs on Fedora Core 5 too:
import os import sys import tempfile import subprocess def test(n): chunk = ': +++ abcd +++' for i in xrange(n): tf = tempfile.NamedTemporaryFile() tfName = tf.name tf.seek(0) tf.write(str(i) + chunk) tf.flush() if not os.path.exists(tfName): print 'pre-check: %s not there' % tfName subprocess.Popen(['strings', tfName]) if not os.path.exists(tfName): print 'post-check: %s not there' % tfName
And here is a typical run, with the boring bits removed for ease of reading:
>>>>>test(30)
0: +++ abcd +++ 1: +++ abcd +++ [ more of the same ] 14: +++ abcd +++ strings: '/tmp/tmpOALbx9': No such file 16: +++ abcd +++ 17: +++ abcd +++ 18: +++ abcd +++ [ more of the same ] 27: +++ abcd +++ strings: /tmp/tmpdc52Nz: No such file or directory 29: +++ abcd +++
Curiouser and curiouser... not only does os.path.exist always report the temp file as existing (at least in my tests), even when strings can't find it, but strings returns different error messages.
Is it possible this is a bug in strings?
What /you/ are seeing is not a bug, I think. Popen() is asynchronous,
therefore you may enter the second iteration -- which implicitly closesthe
temporary file -- before strings actually tries to access it. Use call()
and everything should be fine.
Thanks A LOT, works fine, I feel kind of silly; your diagnostic is
pretty obvious, afterward... I felt uneasy not closing the Popen, but
it worked, so why bother? Its so easy to make ugly code! This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Pierre Rouleau |
last post by:
Hi all!
I am using Python 2.3.1 on Win32 (NT, 2000).
Whenever a file imports the standard tempfile module, Python 2.3.1
issues the following...
|
by: cherico |
last post by:
from tempfile import *
f = NamedTemporaryFile ()
f = write ( 'test' )
print f.read () #here print nothing
why is it nothing to read()?
I...
|
by: marco |
last post by:
Hello,
I having a problem creating directories with Python 2.3.4
(compiled with gcc 3.2.2, under Linux 2.4.20-31.9).
I'm writing a plugin...
|
by: Lee Harr |
last post by:
Is there any other reason to use a named tempfile other than
to be able to open it again? I am trying to understand this
section of the...
|
by: Gregory Piñero |
last post by:
Hey group,
I have a command line tool that I want to be able to call from a
Python script. The problem is that this tool only writes to a file....
|
by: James T. Dennis |
last post by:
Tonight I discovered something odd in the __doc__ for tempfile
as shipped with Python 2.4.4 and 2.5: it says:
This module also provides some data...
|
by: billiejoex |
last post by:
Hi there.
I'm trying to generate a brand new file with a unique name by using
tempfile.mkstemp().
In conjunction I used os.fdopen() to get a...
|
by: samir.vds |
last post by:
Hello everyone,
I'm trying to test the tempfile module with the following script,
which basically creates a temporary file, fills the file with...
|
by: byte8bits |
last post by:
Wondering if someone would help me to better understand tempfile. I
attempt to create a tempfile, write to it, read it, but it is not
behaving as I...
|
by: concettolabs |
last post by:
In today's business world, businesses are increasingly turning to PowerApps to develop custom business applications. PowerApps is a powerful tool...
|
by: teenabhardwaj |
last post by:
How would one discover a valid source for learning news, comfort, and help for engineering designs? Covering through piles of books takes a lot of...
|
by: Kemmylinns12 |
last post by:
Blockchain technology has emerged as a transformative force in the business world, offering unprecedented opportunities for innovation and...
|
by: CD Tom |
last post by:
This happens in runtime 2013 and 2016. When a report is run and then closed a toolbar shows up and the only way to get it to go away is to right...
|
by: CD Tom |
last post by:
This only shows up in access runtime. When a user select a report from my report menu when they close the report they get a menu I've called Add-ins...
|
by: Naresh1 |
last post by:
What is WebLogic Admin Training?
WebLogic Admin Training is a specialized program designed to equip individuals with the skills and knowledge...
|
by: Matthew3360 |
last post by:
Hi there. I have been struggling to find out how to use a variable as my location in my header redirect function.
Here is my code.
...
|
by: AndyPSV |
last post by:
HOW CAN I CREATE AN AI with an .executable file that would suck all files in the folder and on my computerHOW CAN I CREATE AN AI with an .executable...
|
by: WisdomUfot |
last post by:
It's an interesting question you've got about how Gmail hides the HTTP referrer when a link in an email is clicked. While I don't have the specific...
| |