Tue 01 Jan 2013 05:44:59 PM UTC, comment #2:
The possible EOL characters are nicely itemized on Wikipedia.
http://en.wikipedia.org/wiki/Newline#Representations
The "\n\r" is certainly not a common one. The crux of my report was my understanding that Matlab's implementation respects all line endings simultaneously ... which isn't clear from the documentation, as it may be interpreted to mean that a single line ending is used for each file and is detected automatically.
Essentially, I was thinking that Matlab's implementation was based on regexp (), and that they had implemented an effective and efficient way of splitting a text file into lines,
However, a quick test shows that my understanding was wrong.
Further the "\r\n" variant also throws an error.
On a related not, while poking about on the internet, I came across a reference to an undocumented functions as the backend to Matlab's strread() and textread(). When passing the 'endofline' as '\r\n|\n\r|\r|\n' to strread() or textread(), I get the same error as for textscan(). So it maybe that dataread() is also the backend for textscan()?
In any event, I'm marking this as "invalid".
|
Tue 01 Jan 2013 11:15:45 AM UTC, comment #1:
First of all, is this really a bug?
(1) At the time I added endofline processing to textscan/textread, the ML docs only mentioned "\n", "\r\n" and "\r" EOLs, plus that a default value for endofline param is to be determined from the file at hand.
==> there's at least a bit of undocumented ML behavior.
(2) In real life I've never seen "\n\r" EOLs.
I did encounter "\n\r" sequences but those usually were meant as special encodings, not EOL sequences.
(3) I wonder if your example is really valid as endofline stuff is only..., well, "supported"? .. when reading real files, not character strings.
FYI: strread.m (textscan's work horse) does:
Note that it may well be that strread.m does it OK just "by accident" :-)
|
Sun 30 Dec 2012 10:13:05 PM UTC, original submission:
While thinking about the textscan()/strread() bugs in the tracker, it occurred to me that the Matlab variants may rely heavily on regexp. To check I ran a test on how Matlab's textscan() handles "endofline" characters.
It appears that Matlab's default value for "endofline" is '\r\n|\n\r|\r|\n'.
My tip is;
And with the tip above, the default branch gives me
Which implies the Octave implementation does not recognize "\r" as an "endofline" character.
|