LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Programming (https://www.linuxquestions.org/questions/programming-9/)
-   -   Confusing issue with Perl regEx - Regex check seems to require variable being set (https://www.linuxquestions.org/questions/programming-9/confusing-issue-with-perl-regex-regex-check-seems-to-require-variable-being-set-4175476223/)

EnderX 09-06-2013 04:05 PM

Confusing issue with Perl regEx - Regex check seems to require variable being set
 
I recognize my thread title might not be quite understandable, and I apologize. The issue is that I have a mailing script I'm trying to work with, and it's throwing some wonky behavior when I try to determine (via regex) part of the title of the files I'm attempting to send.

I'm trying to crib this off of a program I inherited from my predecessor. The code is opening a directory, looking at the files inside it, and attempting to match them to a pattern in order to continue processing the file. The original code was looking for a specific phrase to be in the file name, then looking for it to end in a numeric value followed by '.txt'. Both of these appear, as far as I can tell, to be regex setups working against $_.

I was requested to make a change to this program, adding the word 'Urgent' to the subject line of the sent email if said word appeared in the name of the file to be sent. If I use the regex structure the same way my predecessor did (as the content of an if check), I was always getting the 'else' branch regardless of what file it looks at.

In desperation, I tried to set a variable equal to the same regex, so I could write to the stdout what the results were and at least see what it thought it was doing. The variable appears to be getting set to null, but as long as that line is active in the code, the regex appears to work on the if branch now.

Because it seems to work, I can probably go ahead with my work, but I'm confused and a bit alarmed about this behavior. I don't know why it's doing this, which means that I don't know what else it might be breaking behind the scenes, nor how to fix it if it does break.

Would someone please be kind enough to share some suggestions as to what the hey is happening here, and where I might be able to go to look up more information about it?

This is running on a SuSE 11 machine.

The code in question I can trim down to the sample in the block below and still get the same behavior. The line in red is the one whose presence or absence makes the difference in how it acts.

Code:

#!/usr/bin/perl

use strict;
use warnings;
use diagnostics;
use Net::SMTP;
use MIME::Lite;

my $count;
my @strucs;
my $p1;
my $p2;
my $filenm;

my $x;
my $datadir = "/srv/www/htdocs/Survey_forms/";

my $realFile;

my $ker;

opendir DH, "$datadir" or die " could not read listing: $!";
while ($_ = readdir(DH))
{
        if (m/Survey_Results_/g)
        {

                $p1=pos $_;
                $count++;
                print "\n$count" . ') ';
                print $_, " " x (30-length($_));
                push @strucs, $_;
                print "\n";
                if (m/[0-9].txt/g)
                {
                        $realFile = $_;
                        print "Real File = $realFile\n";
                        print "Parse File = $_\n";
                        $ker = m/Urgent/gi;
                        print "Parse File = $_\n";
                        if (m/Urgent/gi)
                        {
                                $filenm = substr($_, 21, 20);
                                print "Foo!\n";
                        }
                        else
                        {
                                $filenm = $_;
                                print "Bar!\n";
                        }
                        print "$filenm\n";
                }
        }
}


j-ray 09-07-2013 04:36 AM

while ($_ = readdir(DH))

if you use $filename instead of $_ the whole thing becomes easier as $_ is used by perl frequently and so may contain a different value than expected.


All times are GMT -5. The time now is 10:38 PM.