 |
lua-l archive |
|
|
||
|
I am not sure your suggestion fixes these problems.
You're right. It really only ameliorates the "Unix versus DOS" problem. In other words, it still assumes that there is a single char which uniquely determines "end of line" (or "end of block of data"), and in that regard isn't much better than "*l".
I just think that completeness requires that you be able to reconstruct the input data after receiving it, and it seems a pity that you can't do that if you want to use "*l" -- you have to implement your own buffering in Lua on top of the buffering already implemented below.
This is a nicer request. Maybe I should return the detected line break as an extra argument?
That was my first thought, except that it isn't enough because recvline() currently eats _all_ CR characters in the line, not just a final one before the LF. So the line:
"hello CR gday CR CR LF" turns into "hello gday" Returning the actual line-break would give: "hello gday" (+CR) Neither of these allows the input to be reconstructed.I guess the most generic way to do this would be to allow a string matching pattern to be specified, so it would be easy to solve the Mac versus Unix versus DOS problem," for instance. (Line ends at the first CRLF, LF alone, or CR alone, which is then consumed and returned with the line.)
But that's getting complicated.