painter@sequoia.execu.com (Tom Painter) (02/27/91)
I'm having a little problem with the $& notation. I haven't seen any mention of this in the book. It seems that the string that is matched is actually the string that appears in the script rather than the actual match from the input. This results in problems when there is a case difference. Observe: Input: This is in a file. THIS IS IN A FILE, TOO. Script: #! /usr/local/bin/perl -n m/FILE/i; print $` . $& . $'; Output: This is in a FILE. THIS IS IN A FILE, TOO. Note that the word file in the first line has changed case. #include <typical-PERL-questions.h> Am I missing something? Is this fixed after PL41? Is there a work-around? Thanks Tom -- ----------------------------------------------------------------------------- Tom Painter UUCP: ...!cs.utexas.edu!execu!painter Execucom Systems Corp., Austin, Texas Internet: painter@execu.com (512) 327-7070 execu!painter@cs.utexas.edu Disclaimer: My Company? They'll claim all my waking hours, not my opinions. -----------------------------------------------------------------------------
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (02/27/91)
In article <32947@sequoia.execu.com> painter@sequoia.execu.com (Tom Painter) writes:
:
: I'm having a little problem with the $& notation. I haven't seen any
: mention of this in the book. It seems that the string that is matched
: is actually the string that appears in the script rather than the
: actual match from the input. This results in problems when there is a
: case difference.
:
...
:
: Am I missing something? Is this fixed after PL41? Is there
: a work-around?
No, it's a real bug. It will be fixed in 4.0. The workaround is to
force the optimizer to hand the pattern off to the real pattern matcher:
/FIL[E]/i
or
/\bFILE/i
or
1 && /FILE/i;
Larry