[wellylug] Perl regular expression problem with literal $
Cliff Pratt
enkidu at cliffp.com
Mon Jun 2 21:26:22 NZST 2008
Peter Davenport wrote:
>
>
> Date: Sun, 01 Jun 2008 12:51:35 +1200
> From: Cliff Pratt <enkidu at cliffp.com <mailto:enkidu at cliffp.com>>
> Subject: Re: [wellylug] Perl regular expression problem with literal $
> To: Wellington Linux Users Group <wellylug at lists.wellylug.org.nz
> <mailto:wellylug at lists.wellylug.org.nz>>
> Message-ID: <4841F297.7070409 at cliffp.com
> <mailto:4841F297.7070409 at cliffp.com>>
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
>
> >Peter Davenport wrote:
> >> Not a direct Linux issue, but I do run this process under Linux.
> >>
> >> I have a perl script to process some data with many records of
> the form -
> >> 'User xxxxxx transfered 123456kb of file yyyyyy at cost of
> $1,234.56 to
> >> machine zzzzz'
> >>
> >> This example is a bit made up but it illustrates the point. I am
> trying
> >> to extract the numbers for the kb and $.
> >>
> >> My perl RE to get the kb is m/ (\d+)kb / and this works as it
> gets the
> >> leading/trailing blanks and the numeric kb item into $1 variable.
> >> However, for the money item, I tried m/ $([\d,.]+) / but the $
> gets used
> >> to indicate the end of record. Escaping it with backslash dosn't
> work
> >> either as it then seems to get interpreted as the start of a
> >> scalar variable. How do I specify a literal $ in the RE?
> >>
> >> This data extraction requirement must be a common one and been
> solved
> >> before. I have not been able to locate a solution.
> >> Can anyone help to resolve this please.
> >>
>
> >
>
>
>
> >It's not matching your RE. The RE should read:
> >/ \$([\d.]+ )/
> >
> >Note, no comma.
> >
> >Here's my test snippet:
> >
> >#!/usr/bin/perl
> >
> >use strict ;
> >use warnings ;
> >
> >my $str = 'abcdef $1234.00 xyz' ;
> >print "$str\n" ;
> >$str =~ / \$([\d.]+ )/ ;
> >print "$1\n" ;
> >
>
> Thank you for this response. The escape of the $ character was part
> of the answer that I needed, but that did not fix it completely. The
> example code worked so I knew what to persevere with that. I had a
> prior match statement with a 'g' option for global and that seemed
> to swallow up the whole record and thus not match the bit I wanted
> to extract on the later statement. Removing the 'g' from the prior
> statement fixed it. I had not expected such interaction between
> statements.
>
That's interesting. Care to share a bit more of the code? I was thinking
that the comma was the problem, but I see now that it wasn't. I don't
know why I thought that now!!
It is useful to know that a bit of code works, isn't it?
Cheers,
Cliff
More information about the wellylug
mailing list