[
https://issues.apache.org/jira/browse/IO-335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778414#comment-13778414
]
Lantao Jin commented on IO-335:
-------------------------------
Thank you. But it reminded me that the same approach to terminated a line in
java.io.BufferedReader#readline()
/**
* Reads a line of text. A line is considered to be terminated by any one
* of a line feed ('\n'), a carriage return ('\r'), or a carriage return
* followed immediately by a linefeed.
* … */
String readLine(boolean ignoreLF) throws IOException {
…
Perhaps, Java always regard them as the same. I'd better change my own code to
adapt to it.
> Tailer#readLines - incorrect CR handling
> ----------------------------------------
>
> Key: IO-335
> URL: https://issues.apache.org/jira/browse/IO-335
> Project: Commons IO
> Issue Type: Bug
> Reporter: Sebb
> Assignee: Sebb
> Fix For: 2.4
>
>
> The readLines method checks for CR. If found, it is not stored immediately,
> but a flag is set.
> If the next char is an LF, the buffer is passed to the listener without the
> CR.
> As soon as the next non-LF (and non-CR) character is received, the saved CR
> is written to the buffer.
> The net result is that CR before LF migrates to the start of the next
> non-empty line, and repeated CRs are collapsed. This is clearly wrong.
> The original code (before IO-274) used RandomAccessFile#readLine() which
> returns on CR, LF or CRLF.
> It looks as though the intention was to retain this behaviour whilst not
> blocking.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
