Re: backslash escapes in character strings

[Andy Adler]

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.

Andy