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

The bug is in your script, not in Lua.

You are saving CRLF-strings to the file opened in text mode.

As a result, all LF are implicitly converted to CRLF.

Just look in "test.txt" with a hex editor: instead of

"1234567890"..LF..CR..LF

you actually have

"1234567890"..CR..LF..CR..CR..LF

in the file.

Ha, thx for pointing that out! Very helpful.

But… it gives different results, but they are still unexpected. There are discrepancies between platforms in how text is treated. After adding the “B” when writing, these are the results;

Mac:

----

Lua 5.3

Testing mode: *l
10	1234567890
10	1234567890
1	CR
11	1234567890+CR
11	1234567890+CR
0	
10	1234567890

Testing mode: *L
11	1234567890+LF
11	1234567890+LF
2	CR+LF
12	1234567890+CR+LF
12	1234567890+CR+LF
1	LF
10	1234567890
Program completed in 0.16 seconds (pid: 86623).

Windows:

--------

Lua 5.3

Testing mode: *l
10	1234567890
10	1234567890
0	
10	1234567890
10	1234567890
0	
10	1234567890

Testing mode: *L
11	1234567890+LF
11	1234567890+LF
1	LF
11	1234567890+LF
11	1234567890+LF
1	LF
10	1234567890
Program completed in 0.25 seconds (pid: 18632).

So with the “*l” option on Windows it converts line endings, but on Mac it does not, Mac retains the CRs, which seems weird.

And with “*L” on Windows it does not actually “retain" the line endings, because it only retains them AFTER conversion.

I would have expected either of the following to be consistent across platforms, or both of them to make them safer:

1) on Mac, to also convert “CRLF” to “LF”, when using “*l”

2) on Windows, to NOT convert “CRLF” to “LF” when using “*L”

Thijs