Re: backslash escapes in character strings

[John W. Eaton]

On  2-Apr-2005, Andy Adler <address@hidden> wrote:

| On Fri, 1 Apr 2005, John W. Eaton wrote:
| 
| > I think we may have discussed this before, but I'm not sure what the
| > outcome was.
| >
| > Currently, Octave converts things like
| >
| >   "foo\nbar"
| >
| > to the sequence of characters
| >
| >   f o o LF b a r
| >
| > at the time the string is parsed (LF is the ascii linefeed character,
| > 0x0A).  In Matlab, there is no conversion, so the sequence of
| > characters is
| >
| >   f o o \ n b a r
| >
| > The \n is only special in some contexts, like when it is passed
| > through fprintf (as far as I know, in Matlab, if you want to embed a
| > LF character in a string, you need to use something like
| >
| >   s = sprintf ('foo\nbar');
| >
| > Should Octave continue to behave as it does, or should it try to be
| > compatible here as well?
| 
| Matlab does not have a good record for staying consistent with themselves.
| I noticed this while writing the sparse functions - I based it on Matlab4,
| but the behaviour had changed by v6.
| 
| To me, expecially given the setstr example, this sounds like a place
| where Matlab may change.
| 
| Also, I doubt many people understand how Matlab actually works here
| (it was certainly news to me). Therefore code that depends on this
| "feature" will almost certainly be by mistake, rather than by design.
| 
| > In addition to compatibility with the other leading brand, the real
| > reason for wanting this change in behavior is that it makes things
| > like
| >
| >   cd c:\foo\bar
| >
| > work as Windows users would expect without making cd a special command
| > (and introducing likely inconsistencies with other commands).
| 
| I had assumed that Matlab had a 'special' cd command. As you point out,
| making cd special has it's problems. My question is whether they are
| really worse than the other path you suggest.
| 
| Now that I think about it, making cd special will only solve
|     cd 'C:\progra~1\MATLAB6p5\work'
| but not
|     x='C:\progra~1\MATLAB6p5\work';
|     cd(x)
| 
| My vote is that this is not important enough to make a big work around.
| It would be neat to allow the former. Perhaps it could be possible to
| give access to the unparsed command. That way 'cd' (and other *oct or
| *m files people write) can do special things like this.

That is the intent of the new "raw command" (see "mark_as_rawcommand",
"unmark_rawcommand", and "is_rawcommand") implemented for gnuplot
syntax, but I'm now thinking that it is just a temporary fix and not
something we want to use extensively.  Instead, for gnuplot, we should
probably be writing all gnuplot commands explicitly with some kind of
function that is equivalent to the current "graw" (or
"__gnuplot_raw__") function.

Given the lack of response in the last two weeks, it seems that there
is not a lot of concern about this issue either way.  I think it would
be good to be compatible, so I recently checked in some changes to
make Octave have more compatible single quoted strings.  Of course,
some issues came up that I wasn't anticipating, but I think they have
all been resolved adequately:

  * All strings stored in .mat files are considered to be single
    quoted.  So if you save a double quoted string in a .mat file and
    then reload it, it will change to a single quoted string.  There
    is currently no warning about this, but we could warn on saving.

  * The result of concatenating a mixture of double and single quoted
    strings is a double quoted string.  Octave will warn about this.
    You can turn off the warning by setting the new built-in variable
    warn_string_concat to false.

  * As mentioned in my original message, for compatibility,
    expressions like char ([102, 111, 111]) always produce single
    quoted strings.  If you pass a double quoted string to char (or
    setstr) it will return a double quoted string.

jwe