Message106999
The following snippet of code is a concise way to exhibit the problem:
import os
wr = open('/tmp/test', 'w')
wr.write('oink\noink\n')
rd = open('/tmp/test', 'r')
rdlns = open('/tmp/test', 'r')
# first, read til EOF is reached (which is right away)
assert len(rd.read()) == 0
assert len(rdlns.readlines()) == 0
# add data to the file
wr.flush()
# try to read again
print 'read : ', rd.read().split() # fails
print 'readlines: ', rdlns.readlines() # fails
print 'readline : ', rdlns.readline().strip() # succeeds
# cleanup
wr.close()
rd.close()
rdlns.close()
os.remove('/tmp/test')
On Linux, here is the output:
$ python2.6 src/readlines.py
read : ['oink', 'oink']
readlines: ['oink\n', 'oink\n']
readline :
On Solaris, here is the output:
$ python src/readlines.py
read : []
readlines: []
readline : oink
The problems comes from the fact that once EOF is reached, nothing more will be read from the file on subsequent reads, as noted in the manual page (http://docs.sun.com/app/docs/doc/816-5168/getchar-3c?a=view):
"If the stream is at end-of-file, the end-of-file indicator for the stream is set and these functions return EOF. For standard-conforming (see standards(5)) applications, if the end-of-file indicator for the stream is set, these functions return EOF whether or not the stream is at end-of-file."
The attached diff fixes the problem. |
|
Date |
User |
Action |
Args |
2010-06-03 23:50:45 | kalt | set | recipients:
+ kalt, theller |
2010-06-03 23:50:44 | kalt | set | messageid: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za> |
2010-06-03 23:50:43 | kalt | link | issue8893 messages |
2010-06-03 23:50:42 | kalt | create | |
|