octave-maintainers
[Top][All Lists]
Advanced

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

Re: Backslashes in regular expression replacement patterns


From: Rik
Subject: Re: Backslashes in regular expression replacement patterns
Date: Wed, 17 Oct 2012 12:11:51 -0700

On 10/17/2012 10:46 AM, John W. Eaton wrote:
> On 17-Oct-2012, Rik wrote:
>
> | With an expression like "\$1" the
> | interpreter itself does one round of escape sequence processing and changes
> | this to "$1".  So when I get the replacement string in regexprep I already
> | can't tell whether the user typed "\$1" or "$1".
>
> I don't see that this matters.  For example, if to pass the two
> character sequence \t to regexp with a double quoted string, you have
> to write it as "\\t".  The only question I see is whether we should be
> converting unrecognized \X sequences in double quoted strings to X.
I can see both sides of this issue.  As a first data point, existing
languages are inconsistent.  I just tried tcsh and sh and they do not
convert unrecognized escape sequences.

sh:
x="a\jb"
echo $x
a\jb

On the other hand, Perl does have Octave's behavior
$x="a\jb";
print $x,"\n";

And when I run that program I get
Unrecognized escape \j passed through at blah.pl line 3.
ajb

There's no consistency and Matlab is not a reference since they don't use
double-quoted strings.

I suppose one way to look at it is to consider escape sequence processing
as a simple form of search and replace pattern matching.  If the search
pattern isn't found exactly, should we really be altering the string?  On
the other hand, this is just a design choice and it has already been made
in one particular direction.  Why bother to change anything and complicate
our lives?  I'm leaning towards doing nothing.

--Rik




reply via email to

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