Bug #15600
closedCSV underlying IO object is not getting rewound after parsing
Description
Hello,
Sorry if this bug has already been reported but I couldn't find any reference to it.
For the following CSV test.csv file:
a,b,c,d
1,2,3,4
5,6,7,8
9,10,11,12
and the following code snippet:
require 'csv'
csv = ::CSV.open('./test.csv', {headers: true, col_sep: ','})
p csv.eof?
csv.readline
p csv.eof?
csv.readline
p csv.eof?
csv.readline
p csv.eof?
I got the following results with 2.6.1:
false
true
true
true
but using ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-darwin16]
I got:
false
false
false
true
It might be an intentional behaviour but in that case, I can't see anything in the documentation explicitly saying that we shouldn't rely on the underlying IO object to know the state of the current CSV object (as it was possible in the previous minor version) and couldn't find the related changelog.
Thanks for your work.
Updated by nobu (Nobuyoshi Nakada) about 5 years ago
- Status changed from Open to Third Party's Issue
It might be an intentional behaviour but in that case, I can't see anything in the documentation explicitly saying that we shouldn't rely on the underlying IO object to know the state of the current CSV object (as it was possible in the previous minor version) and couldn't find the related changelog.
You can report this to the upstream of CSV.
I guess it has never guaranteed such assumption, though.
Updated by chi (Chi Leung) about 5 years ago
Hi nobu, thanks for your reply.
I guess it has never guaranteed such assumption, though.
Sorry, what I meant is that I don't understand why #eof?
would be part of the CSV object public API if it doesn't reflect the state of the current object anymore and was never meant to do.
I will raise a ticket on the upstream repository.