This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author kalt
Recipients kalt, theller
Date 2010-06-03.23:50:41
SpamBayes Score 0.0035781646
Marked as misclassified No
Message-id <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
In-reply-to
Content
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.
History
Date User Action Args
2010-06-03 23:50:45kaltsetrecipients: + kalt, theller
2010-06-03 23:50:44kaltsetmessageid: <1275609044.71.0.537925857344.issue8893@psf.upfronthosting.co.za>
2010-06-03 23:50:43kaltlinkissue8893 messages
2010-06-03 23:50:42kaltcreate