Skip Menu |

This queue is for tickets about the Parse-RecDescent CPAN distribution.

Report information
The Basics
Id: 56662
Status: resolved
Priority: 0/
Queue: Parse-RecDescent

People
Owner: Nobody in particular
Requestors: anand.vn [...] hcl.in
Cc:
AdminCc:

Bug Information
Severity: (no value)
Broken in: (no value)
Fixed in: (no value)



Subject: Escape Sequences Not Parsing - Recdescent
Date: Fri, 16 Apr 2010 18:32:38 +0530
To: "bug-Parse-RecDescent [...] rt.cpan.org" <bug-Parse-RecDescent [...] rt.cpan.org>
From: "Anand Venkatesan, ERS, HCLTech" <anand.vn [...] hcl.in>
Hi Damian, I'm trying to parse the escape sequences like \n \t using Rec-descent parser, but the REGEX I used in the production unit is not parsing the escape sequences present in my input. Here my piece of code taken from my actual lengthy program, Recdescent version : Parse-RecDescent-1.964 Perl Version : v5.8.8 built for MSWin32-x86-multi-thread ### Program Starts #### use strict; use warnings; use Parse::RecDescent; my $Parser = q{ start : parse_it(s) parse_it : parse_slash_anychar | <error> parse_slash_alphabet : /\\./ {print "Parsed Escape Sequences $item[1]\n";} #Here it Should be /\\\./ but don't know why so }; my $Data = join '', <DATA>; my $C_Parser_Obj = Parse::RecDescent->new($Parser); $C_Parser_Obj->start($Data); __DATA__ \n \t ### Program Ends ### I found when I use REGEX /\\./ it is not parsing \n or \t. But when I use REGEX /\\\./ it is parsing without any error. But I believe it should work with double front slash instead of triple. I'm facing this problem only inside the Recdescent, but in normal PERL REGEX programs it is working fine with double front slash itself. Shall I know this is how the Recdescent package developed or this was an unexpected one? Based on which I will change all the similar occurrences in my program. Thanks, Anand V DISCLAIMER: ----------------------------------------------------------------------------------------------------------------------- The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or HCL or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of HCL or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately. Before opening any mail and attachments please check them for viruses and defect. -----------------------------------------------------------------------------------------------------------------------
Subject: Re: [rt.cpan.org #56662] Escape Sequences Not Parsing - Recdescent
Date: Fri, 16 Apr 2010 14:32:04 +0100
To: bug-Parse-RecDescent [...] rt.cpan.org
From: Damian Conway <damian [...] conway.org>
Hi Anand, What you're seeing is not a bug, but just the way that q{...} strings always work in Perl. Because the regex your using is defined inside a single-quoted string, it is subject to the same rules as the contents of every other single quoted string. So if you want \\. literally inside your regex (inside the string), then you need to backslash the first of those backslashes so the surrouding q{...} ignores it. That means you do actually need three backslashes in the q{...} to get two in the regex so as to then match one in input. If you only use two, then the first one escapes the second one for the q{...}, leaving only one backslash for the regex to see, and so the regex uses that one to escape the following dot, instead. You can see the cumulative effect by running the following code snippet: my $three_slashes = q{\\\.}; my $two_slashes = q{\\.}; print $three_slashes, "\n"; print $two_slashes, "\n"; my $three_slashes_regex = qr{ $three_slashes }; my $two_slashes_regex = qr{ $two_slashes }; print $three_slashes_regex, "\n"; print $two_slashes_regex, "\n"; Notice that the two-slash version ends up being the pattern / \. /, which is an escaped dot metacharacter, not an escaped slash followed by the dot. Hope this helps, Damian
According to the ticket history, this item should be resolved.