Re: Mac text files and gets()
Robert Craig wrote:
>
> CChris wrote:
> >
> > CChris wrote:
> > >
> > > I happened to have a text file with \r line terminators on my HD, and
> > > wanted
> > > to process it using gets(). It didn't work the expected way.
> > >
> > > I ran the following test:
> > > }}}
<eucode>
> > > integer fh
> > > fh=open("test.txt","wb")
> > > puts(fh,{65,10,66,26})
> > > close(fh)
> > > fh=open("test.txt","r")
> > > ?gets(fh) -- {65,10}
> > > ?gets(fh) -- {66}
> > > ?gets(fh) -- -1
> > > ?machine_func(26,0)
> > > </eucode>
{{{
> > >
> > > This shows that a Unix style file can be read properly.
> > > Now replace 10 by 13 in the puts() sequence (this is how a Mac file would
> > > look
> > > like), and the output is
> > > {65,66}
> > > -1
> > > -1
> > > Not the expected thing.
> > >
> > > Since it is about as likely, under Windows, to have Unix files or Mac
> > > files
> > > on one's HD, isn't fixing/extending gets() to handle both formats a good
> > > idea?
> > > No need to modify the behaviour of EGets() for stdin, so changing lines
> > > 2668-72
> > > in be_runtime.c from
> > > if (c <= '\n') {
> > > if (c == '\n') {
> > > break;
> > > }
> > >
> > > to
> > > if (c <= '\r') {
> > > if (c == '\n') {
> > > break;
> > > }
> > > if (c == '\r') {
> > > c = '\n';
> > > break;
> > > }
> > > should be enough. The extra test is taken only if a character in the 0.13
> > > range
> > > (a control charatcter) is read, so the impact should be nil on text files.
> > >
> > > Did I miss some ripple effect?
> > >
> > > CChris
> >
> > Since there were exactly zero comments regarding this earler post, I'll
> > update
> > the backend and the doc for gets() this weekend, unless there is a late
> > outcry.
>
> I don't think this is a good idea.
>
> > Addiionally, I'll consider changing the second test to "<=", so that VT and
> > FF are also treated as EOL by gets(). This can be useful when importing
> > files
> > output by mainframe computers, and is already implemented in the D language.
>
> I don't think this is a good idea either.
>
> You will break some existing Euphoria for Windows/DOS programs
> in the name of added convenience in reading Mac files, an O/S
> that currently is not supported by Euphoria. Wait until there
> is a Mac version of Euphoria.
> I'm sure there are other Euphoria programs, such as ed,
> and possibly other places in the interpreter,
> that also assume DOS/Windows (or sometimes) Linux,
> line terminators, so your "enhancement" will not be complete,
> and will just cause confusion.
> There's already enough confusion in DOS/Windows
> due to the silly distinction Microsoft makes between
> "text" and "binary" files. Don't make it even more confusing.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> <a href="http://www.RapidEuphoria.com">http://www.RapidEuphoria.com</a>
Huh?
The point is to make isolated \r (and possibly ASCII 11 and 12) be _also_
recognised as line terminators, not instead, not anything more.
If gets() encounters ASCII 10, it currently treats it as EOL and returns a line
ending in \n (which happens to be the same);
If gets() encounters ASCII 13, then ASCII 10, it does the same.
The proposed enhancement is to treat ASCII 13 not followed by ASCII 10 in the
same way. This can be done bt treating \r as line terminator on its own, and
ignoring a \n that would immediately follow.
I have the feeling, as I read your comment, that you understood something else
and farther reaching. Not sure what, though. The behaviour of gets() on
Unix/DOS/Windows text files would _not_ be changed at all. The only change is
that, if a file is opened in text mode and has isolated \r (ie not followed by
\n) inside, these will be read as EOL while they currently aren't. Which sort of
code will this break, and which sort of text files Eu code currently processes
would exhibit this pattern?
CChris
Bernie:
Since Eu is not ported on Mac yet, there is no provision yet to output \r line
terminators. This will happen in due time, and is not useful before. The mod I'รน
suggesting only concerns gets(), which doesn't write anything. It is supposed to
be used only when reading text files, for which lines make sense.
Further: even though Eu is not supported on Mac, it doesn't mean that it should
not be able to process text files produced by a Mac, as these files may not be
related with programming at all. I have files that use the Unix and Mac formats
on my HD, even though I'm only using Windows, for instance. Yet I can use an Eu
program to process files produced on Unix systems, but not on OS/X systems. This
is the only thing I'm attempting to fix. All text editors transparently read all
three formats nowadays.
|
Not Categorized, Please Help
|
|
