Re: Windows query

["Cezary H. Noweta" <chn@...>]

Hello,

> 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