lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


No, what I mean is: if it reads a Windows-formatted text file
under _Windows_ in one go, with "*a", do the two-character line
endings get converted into one-character line endings?

In general, yes --- \r\n is converted to \n on the fly. However... ;)

In particular, such translation occurs in a case of files opened in a text mode.

From Lua's POV it is impossible to open file in a text mode explicitly, as lua_checkmode() (or l_checkmode() in Lua 5.3) does not allow 't' flag in 'mode' parameter (quite fine as 't' is not standard opening mode indicator). If you will not append 'b' to 'mode' then a given file is opened in 'default' (text in most cases) mode.

What is 'default' mode? According to the C Standard it is a text mode, but under Win it depends on library and link options used during making of Lua binary.

Default 'default' ;) is a text mode. However, if Lua was linked with binmode.obj (MSVC, WATCOM) then 'default' is a binary mode for opening files.

So, the sole case, where ``lines'' in your code could contain trailing \r under Win is a case when Lua binary is linked with binmode.obj or is using some strange C library (very uncommon and exceptional cases, occurring where one knows well what he is doing as it violates the C Standard).

(I know that the portable way is "lines", I'm just wondering
how portable :read"*a" is.)

:read "*a" is portable in a same way as a standard C text stream read functions are portable. I.e. there could be a platform/implementation on which :read "*a" of Holy Bible gives you ''I need to talk to you like a hole in my head --- The Lord'' and as far as writing the above sentence to a text stream will produce a whole Holy Bible text it will be conforming C implementation. ;)

File of a text stream is ``external representation'' --- there is no requirement that ,,Hello'' cannot be represented as ``Bye'' in the external representation (file) as far as writing ``Hello'' produces ``Bye'' in a file and further reading of this file returns ``Hello'' (certainly, writing ``Bye'' cannot produce ``Bye'' as it is already reserved for representing ``Hello'' ;)

Above idiotic example is for illustration of a fact that ``text stream'' artifacts are kept mainly for streams which are not linked with disk files or Win's stupid \r\n -- in fact it produces a lot of problems (like seeking). Today, a file is what it is ;) --- currently there are no TRS/CPM's fabrications --- thus it is a good idea to open files in a binary mode and to treat \r\n as \n internally, or, simply, to treat \r as the last char of a line. There is no problem to operate on/produce canonically terminated lines in files under Windows. There is no need to shake the universe for the sake of holy cows and notepad users. I hope MS will not produce Win11 with ``Hey, this is the end of a line nr beginofnumbermark\d+endofnumbermark'' translated to Coptic in MSUTF13 as line endings (certainly with 500pp. paid specification). ;)

-- best regards

Cezary H. Noweta