Incoherent handling of '\n' in Octave 2.9.9 wrt. Octave 2.1.73

[Paolo Giarrusso]

On 4/18/08, John W. Eaton <jwe at bevo.che.wisc.edu> wrote:
> On 18-Apr-2008, Paolo Giarrusso wrote:
>
>  | (Semi-automatic) Bug report for Octave 2.9.9 configured for x86_64-pc-linux-gnu
>  |
>  | Description:
>  | -----------
>  | The attached code snippet gives different result when executed with
>  | Octave 2.1.73 and Octave 2.9.9, as provided by Ubuntu 7.04 (and I
>  | consider the results of 2.9.9 to be buggy). The results of each
>  | command in Octave2.9 are given in comments.
>  |
>  | In particular, what puzzles me is that disp('\n') (note single quotes)
>  | prints literally the blackslash and the `n', while disp("\n") and
>  | fprintf (of either '\n' or "\n") give the expected result.
>  | Typing the string at the prompt behaves like disp:
>  |
>  | octave2.9:3> '\n'
>  | ans = \n
>  | octave2.9:4> "\n"
>  | ans =
>
>
> Octave recognizes C-style backslash escapes in "" quoted character
>  strings.  This is not done in '' quoted character strings for
>  compatibility with Matlab.
>
>
>  | But fprintf() gives the same results with both single and double
>  | quotes; however, it sure does not handle \n itself, because it would
>  | then handle:
>  |
>  | octave2.9:5> str=disp('\n')
>  | str = \n
>  |
>  | octave2.9:6> fprintf(str)
>  | \n
>  | octave2.9:7>
>  | But fprintf doesn't handle \n here, as you can see.
>  |
>  | Any hint?
>
>
> I suppose that's a bug.  The disp function is producing a
>  string that behaves as a "" quoted character string even when the
>  input is a '' quoted character string.

No, that string is a literal \n which stays the same, the newlines you
see above are not a translation of the '\n'; both "disp(var)" "var"
and "var= value" (no semicolon) show a newline at the end.

If the bug you describe is that fprintf should interpret that \n, I do
not agree - who used disp() did not want to print an escape, so
fprintf should leave it as is.

I guess that in Matlab fprintf('\n') understands the escape, right?

My questions are:

1) fprintf('\n') works like in C and Matlab anyway. Shouldn't this be
documented here?
http://www.gnu.org/software/octave/doc/interpreter/Formatted-Output.html#Formatted-Output

This behaviour has some pitfalls. I've described some ones below - I
know these are edge cases, but could you document the exact behaviour
in Octave's manual?

2) How can fprintf distinguish between these two cases?

octave2.9:15> fprintf("\\n")
\noctave2.9:16> fprintf(['\', 'n'])

octave2.9:17>

The argument to the two printf calls is the same.

An even more absurd example is:

octave2.9:19> a=['\', 'n']
a = \n
octave2.9:20> b="\\n"
b = \n
octave2.9:21> strcmp(a,b)
ans =  1
octave2.9:22> fprintf(a)

octave2.9:23> fprintf(b)
\noctave2.9:24>

Note that the two string compare equal but give a different output when printed!

3) An Octave 2.9 string, internally, is just of a plain sequence of
characters, or does it include a flag to say whether it was
single-quoted or double-quoted? Shouldn't the second opportunity be
warned against?

In the second case, I understand better what you say here:
> I suppose that's a bug.  The disp function is producing a
>  string that behaves as a "" quoted character string even when the
>  input is a '' quoted character string.

Then disp's output behaves like a '' quoted string, like it should.

4) However, I'm unsure about this case:

octave2.9:11> b=['\', 'n']
b = \n
octave2.9:12> fprintf(b)

octave2.9:13> b=['\', 'n', "\n"]
b = \n

octave2.9:14> fprintf(b)
\n

Is the "\n" to make the string be considered double-quoted?

>  Also, 2.9.9 is obsolete now that 3.0 has been released.  I strongly
>  recommend upgrading to the stable 3.0 release.

Yep, I will compile sources ASAP. Thanks
-- 
Paolo Giarrusso