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

[John W. Eaton]

On 18-Apr-2008, Paolo Giarrusso wrote:

| 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

Then you can write

  fprintf ("\\n")

or

  fprintf ('\\n')

or

  fprintf ('%s', '\n')

or you can complain to the MathWorks about the way character strings
work in Matlab.  If we want compatibility with Matlab (and most users
seem to want that) then we don't get to choose the behavior here.

| 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

Please remember that Octave is developed mostly by volunteers.  If you
think the documentation is lacking, then please consider submitting a
patch.

| 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'])

In the first case, "\\n" is a double-quoted character string with two
characters (\ and n).  The *printf functions in Octave don't perform
additional backslash escape processing on the format argument when the
format argument is a double-quoted character string.

In the second case, ['\', 'n'] is equivalent to '\n' and is a
single-quoted character string.

| 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!

They have to compare equal or we would break a lot of code.  They have
the same contents but they have different types (single-quoted
vs. double-quoted).

| 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?

What do you mean by "second opportunity" here?

| 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?

When you combine single- and double-quoted character strings, the
result is a double-quoted character string.

You can use the typeinfo function to show the internal type name.

With

  warning ("on", "Octave:string-concat")

Octave will warn you when it concatenates a mixture of character
string types.

jwe