Re: EOL characters

[Paul Kienzle]

[continuation of private discussion...]

On Tue, Jun 20, 2006 at 05:04:15PM -0400, John W. Eaton wrote:
> On 20-Jun-2006, Paul Kienzle wrote:
> 
> | Also, but unrelated (other than slowing down my email when trying to
> | track it down), <CR> on the end of the identifier or type lines in
> | the octave file format causes load to fail.  We're not sure what's going
> | on yet. (2.1.72; Cygwin, Debian)
> 
> Is this the text-mode file format?  I think Octave tries to open those
> files in text mode, but it may be that it doesn't do anything if you
> use the binary mount mode for Cygwin filesystems.  I think if you
> choose binary mount mode for a filesystem, Cygwin assumes Unix-like
> behavior and doesn't do any end-of-line translation.  If you are using
> binary mount mode, does changing to text mode avoid the problem?

The system is mounted in text mode.  The following works fine, so it
is not a bug:

        x=ones(2,2,2); save x; load x;

> Should Octave always have to check for LF/CR/CRLF everywhere it looks
> for EOL?  Ugh.

We were trying to construct an octave format data file by hand using
a windows editor which is why we ended up with <CR><LF> line endings.  
If octave format always uses <LF> endings as it does now, this is 
something users on foreign systems can accomodate; it's the workaround 
that we will use.

The error message was confusing:

        ' found in file `x'identifier `__nargin__

That's because the <CR> in the output stream moved back to the start
of the line.  Otherwise it would have been:

        error: load: bogus identifier `__nargin__^M' found in file `x'

The OS X version I have available (2.1.52) uses <LF> for line endings.  
We will need to make sure that the eventual MinGW distribution does so 
as well.  If a file created on one system (<CR><LF>, <CR> or <LF>) cannot 
be loaded on another it would be a problem.

BTW, should the command "save x" also save globals?

- Paul