Re: Mac text files and gets()
[snipped]
>
> > Is there any market for Linux to read D/W files as \n alone?
>
> The problem comes up quite often.
> When using FTP, a file transfer in "text" mode
> will convert the line-terminators appropriately.
> There are also trivial little utility programs
> that can do the same thing. That's how people
> generally handle this problem.
>
Very true, but is this simpler programming?
> > What is the pukka code for:
> >
> > #ifdef EWINDOWS
> > if (!binary_mode) {
> > if (c == '\r') {
> > c = '\n';
>
> There is currently no need to test
> for binary mode in EGets().
> The O/S does the \r\n -> \n thing automatically before
> EGets() sees the characters.
>
Not true under DOS (int #21, ah=#3F will transfer the #0D,#0A byte sequence as
is), and I didn't try reading a file with the raw Windows API.
As Derek said, this is done by the C I/O library.
> > And lastly, what would the full testset be for all concerned to be happy?
>
> I don't think we should bother trying
> to support foreign systems. Just let each version
> of Euphoria do what's right for that platform.
Then Eu under DOS shouldn't be able to read Unix files, and yet it does. Sorry,
but this doesn't make sense to me.
The interpreter doesn't need to parse Mac text file, since Eu is not supported
yet on that platform. Granted. This waas not suggested, by me at least. Text
files may be completely unrelated with Euphroia source, did you know?
> The rules are complicated enough already.
Disagreed. The mod I posted is very simple and works like a charm.
Linux systems may not be too simple indeed - I got into trouble every time I had
to deal wih them.
> It's trivial to write your own mac_gets() or whatever
> using getc() in binary mode.
> To force Euphoria to merge multiple sets of line terminator
> rules, it will have be somewhat incorrect according to any
> one set.
1/ Currently, is gets() yielding an usable result when readint a DOS text file
under Linux? I don't think so, there must be a trailing \r.
2/ I'm just reading the doc for open() This is supposed to be the "Euphoria
Reference anual", right?It does state that "r" is for text file reads, and "rb"
is for binary file reading It also states that:
Output to text files will have carriage-return characters automatically added
before linefeed characters. On input, these carriage-return characters are
removed. ... I/O to binary files is not modified in any way. Any byte values from
0 to 255 can be read or written
So:
* it is not documented that "r" and "rb" are the same under Linux;
* It is said that \r are striped from text files, but this is not true under
Linux when the text file has the DOS/Windows EOL.
So yes, I'd be going to break code that uses opening file modes improperly, and
I don't think that should be a problem. You have done the same when introducing $
and sneakily changed the evaluation rules in 2.5.
Of course, if the documentation is changed to reflect different behaviours of
open() on various platforms, then the code breakage issue would stand. Still \r's
are not handled properly anyway.
CChris
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
|
Not Categorized, Please Help
|
|
