Re: Mac text files and gets()
CChris wrote:
> Actually, the mod as I implemented it works fine under DOS/Windows, because
> the OS takes care of removing the \r.
> Under Linux/BSD:
> * currently, doing gets() on a DOS text file results in returned lines being
> terminated with \r (I doubt the OS filters it out).
> * with my curent implementation, the trailing \r would disappear, but a
> spurious
> extra empty line would be generated by the \n part.
>
> If we are to avoid this, then it looks like, under Linux/BSD, we'd need a one
> char lookahead buffer for gets(). Its contents would be needed so as to
> recoginse
> \r\n as \n, eliminating both the trailing \r and the spurious empty ine.
> However,
> this also means that an extra char has been read at almost all times:
> * open(), close() and seek() must invalidate the buffer;
> * where() must adjust back one char if the buffer is valid.
> This doesn't incur any noticeable performance penalty under Windows: it's the
> same trick I used to remove the get() quirk of needing an extra space always.
> Didn't take the time to test under colinux - my fault, should have read their
> wiki first so as to get it running.
On Linux and FreeBSD, there is no distinction
(in Euphoria or in general) between opening
a file in "r" mode (text) versus "rb" mode (binary).
The Unix world got it right. There is no silly distinction between
"text" and "binary" files. A file is a file. Period.
And '\n' is the *only* character that indicates the end of a line.
'\r' is irrelevant. The O/S never tries to secretly fiddle around
with any bytes or combinations of bytes.
So you wouldn't be able to limit your "enhancement" to just "r" mode,
since Linux/FreeBSD users expect "r" and "rb" to both mean
exactly the same thing:
"give me the straight goods - no smoke and mirrors, no lying
about what bytes are really there".
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
