octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Single vs. Double Quotes


From: Michael Goffioul
Subject: Re: Single vs. Double Quotes
Date: Sat, 15 Oct 2011 18:58:39 +0100

On Sat, Oct 15, 2011 at 6:36 PM, Rik <address@hidden> wrote:
>> the second result. Can anybody confirm? Do we want to change this in octave?
> Ugh.  No.  Every other reasonable lexical interpreter (Bourne shell, C
> shell, Perl, Python, etc.) makes a distinction between single and double
> quotes.  A double quoted string is interpreted such that special escape
> sequences like "\n" are translated into the actual character(s) the
> sequence represents.  In this case, "\n" becomes newline which may be a
> carriage return, CR, line feed, LF, or CRLF depending on platform.  On the
> other hand, sometimes you don't want such interpretation if you are
> actually looking for the '\' character.  The single quotes turn off
> interpretation and makes this possible.  For example, a directory on a
> Windows machine is much easier to type as
>
> dir = 'C:\home\joe\octave\src';
>    rather than
> dir = "c:\\home\\joe\\octave\\src";
>
> It appears that Matlab always uses interpreting quotes even though they
> have used the character that every other interpreter has chosen to mean
> non-interpreting quote.
>
> Maybe this could be programmed into Octave as an option, to switch on the
> fly between treating single quotes as double quotes, but I have my doubts.
> Many .m files within Octave are already programmed assuming this
> distinction exists.  I suppose it could be possible to have Octave do the
> equivalent of regexptranslate() for each single quoted string and then pass
> that result through the ordinary string interpreter.

Maybe you misunderstood me when I asked whether this should be changed?
I didn't mean to change the general behavior of single-quote in octave. I just
meant to fix strread such that '\n' can be used as a delimiter in a
ML-compatible
way.This is could be achieved as easily as:

strrep (delimiter_string, '\n', "\n")

somewhere in strread.m. This would only cover a very specific case, but also
very common case, imo.

But eventually, I don't really care whether we change that or not. I was
merely reporting an incompatible behavior against ML, which I thought was
worth mentioning.

Michael.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]