Sounds like a hack to me. The reference manual explicitly states the following:
The formats "l" and "L"
should be used only for text files.
I also don't see how this is supposed to work looking at the implementation.
What might have been the case is that your files had LF line
endings, but when opening in text mode, the CR was inserted to
"fix" the line endings or the like. Such shenanigans won't happen
in binary mode.
<thijs@thijsschreijer.nl>wrote:
With 'file:read’ the description of the “l” (or “*l” in previous editions) reads: - "l": reads the next line skipping the end of line When testing this on Windows and Mac, it turns out only an LF (char 10) is recognised as a line end. This means that reading a Windows based text file, with CRLF as line endings, the returned lines will have a trailing CR (char 13). My expectations were that it would in all cases treat CRLF and LF The same way, similar to the way the Lua source code can be read. Sample code to show the behaviour: https://github.com/lunarmodules/luasocket/pull/294#issuecomment-1077264055 Is there a specific reason for this behaviour? Did I misinterpret something?I don't have a Windows box to test this on, but if I recall correctly, opening the file in binary mode on Windows should allow 'l' to also trim '\r'. I could be misremembering though. Cheers, Mitchell