[Octave-bug-tracker] [bug #37961] textscan : whitespace specification doesn't work

[Philip Nienhuis]

Follow-up Comment #9, bug #37961 (project octave):

Ben,

There may be a few issues with your changeset, sorry.


(A) I think the first hunk (concerning eol_char) is unwanted. Variable
'eol_char' was only introduced to process the "endofline" parameter for
textscan/textread.
strread.m should have nothing to do with explicit EOLs unless:
- called by textread or textscan
- when the user specifies "endofline" (in fact a textscan/textread parameter)
In all other cases "\n" is part of white space as defined in the ML docs ("
\b\t\r\n"), and as such is implicitly a delimiter.


(B) (I promise it's the last time I mention this) AFAICS Matlab has no
documentation for what happens if there's a literal in a format string that is
simultaneously defined as whitespace. I would be hesitant to "fix" such a
"bug". See (C) below...

FYI, Test #10 in strread.m is an example of reading white space with %s format
conversion specifiers. It boils down to essentially setting whitespace empty
and explicitly specifying delimiter(s). That test is based on older ML docs
and examples.


(C) In newest ML r2013a (prerelease), the OP's problem (with the text in his
original report and his invocation of textscan) gives:

>> fid = fopen ('testfil.txt')

fid =

     3

>> A=textscan(fid,'%s;%s', 'Whitespace', ';')

A = 

    {1x1 cell}    {0x1 cell}

>> A{1}

ans = 

    'XQPCTick'

>> A{2}

ans = 

   Empty cell array: 0-by-1

>> 

... so as his examples no longer works in newest ML I even doubt if ML
compatibility is a valid issue here. (A fine example of why it is unwise to
rely on undocumented ML behavior)

Again, I think the OP simply invoked textscan (1) in a clumsy way with (2)
unfortunately an old and less robust version of the textscan/strread/textread
trio.


(D) The newest on-line ML docs (r2012b) for strread can even be interpreted as
that whitespace MAY only be one of \b \n \r \t \\ \% "'" (intriguingly space
itself isn't mentioned, it used to be in older ML docs).


To Jordi:
Yes I don't see any reason not to apply the most recent
textscan/textread/strread versions to stable (i.e., for the 3.6.4 release).


BTW we're still waiting for the OP's answers.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?37961>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/