>"$1\\2"  (instead of  "${1}2"}
>
>Is this a normal behavior (as I stated I failed to make it work with perl,
>but nobody's perfect) or a transient bug in the escaping process ? I tried

Yes, this is a normal/intentional behavior.  It is a deliberate deviation
from Perl because the Perl behavior is deprecated, being something of an
accident and a vestige of sed.  Backreferences should not be interpreted
outside of a pattern, but Perl interprets them anyway.  I can't find the
reference right now, but I'm fairly certain the Perl docs explicitly
say not to use \1, \2, etc. in place of $1, $2.  Still, the behavior of
Perl hasn't caught up with that recommendation.  So you wind up with
the following silliness:
~> echo foobar | perl -p -e 's/(foo)(bar)/{\2\1}/'
{barfoo}
~> echo foobar | perl -p -e 's/foobar/{\2\1}/'
{}
~> echo foobar | perl -p -e 's/foobar/{\45}/'
{%}
~> echo foobar | perl -p -e 's/foobar/{\83}/'
{83}

In the first and second cases, the backreferences are interpreted (in
the second case they are empty because there were no matched groups).
This is done for \1 - \9.  For \10 and up the escape sequence is treated
as an octal number, so the third case prints '%', ASCII character 045 octal.
Numbers greater than 10 that aren't octal are interpreted literally,
so the fourth case prints \83.  As I indicated in the first email, all
of these behaviors are a byproduct of the Perl language and how it
interprets strings, not the Perl regular expression syntax itself.  When
translating this to Java, it is more appropriate to use Java string
interpretation except for special instances that have a clear bearing
on regular expressions, such as interpolated saved group references.
Since the special instances necessitate the use of escaping characters
(e.g., "\\$") it is more consistent for all escaped characters to be
interpreted literally (instead of just the special ones and treating
an escape literally when preceding normal characters) and to require a
double escape for an escape (e.g., "\\\\") in all cases in the substitution.
In any case, even though you didn't ask for it, that's the whole rationale
for bystanders and I'll make sure it goes into the forthcoming user's guide
along with all the other tidbits from the user and developer mailing lists.

daniel



--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to