[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #38003] textscan() "endofline" compatibility
From: |
Philip Nienhuis |
Subject: |
[Octave-bug-tracker] [bug #38003] textscan() "endofline" compatibility |
Date: |
Tue, 01 Jan 2013 11:15:45 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux i686; rv:10.0.11) Gecko/20100101 Firefox/10.0.11 |
Follow-up Comment #1, bug #38003 (project octave):
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:
octave:4> a = strread (sprintf ('A\r\nB\n\rC\rD\nE'), '%s')
a =
{
[1,1] = A
[2,1] = B
[3,1] = C
[4,1] = D
[5,1] = E
}
octave:5>
Note that it may well be that strread.m does it OK just "by accident" :-)
_______________________________________________________
Reply to this item at:
<http://savannah.gnu.org/bugs/?38003>
_______________________________________________
Message sent via/by Savannah
http://savannah.gnu.org/
- [Octave-bug-tracker] [bug #38003] textscan() "endofline" compatibility,
Philip Nienhuis <=