Re: Unexpected result using file:read("l")

[Mitchell <lists@...>]

Hi Francisco and Lars,

Thanks for the corrections. I was indeed misremembering. I probably just opened files in binary mode in order to handle '\r?\n' in a cross-platform way.

Cheers,
Mitchell

On Thu, 24 Mar 2022 16:06:35 +0100
Lars Müller <appgurulars@gmx.de> wrote:

> 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.
> //
> 
> On 24.03.22 15:39, Mitchell wrote:
> > Hi,
> >
> > On Thu, 24 Mar 2022 13:50:50 +0000
> > Thijs Schreijer<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


Cheers,
Mitchell