CGI/Perl Guide | Learning Center | Forums | Advertise | Login
Site Search: in

  Main Index MAIN
INDEX
Search Posts SEARCH
POSTS
Who's Online WHO'S
ONLINE
Log in LOG
IN

Home: Perl Programming Help: Beginner:
Data block not being picked in code.

 



Tejas
User

Jul 18, 2016, 1:11 PM

Post #1 of 4 (1750 views)
Data block not being picked in code. Can't Post

Hi

Below is the code and the data block.
And the requirement is to check whether 780222306003 exists with My BEING REMOVED as a part of its heading .
And ,'up.v.000652',780222304203exists with LINK BEING REMOVED as a part of its heading


Quote
<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222306003
Station Address:up.v.000652
Time: 1468583578

<INFO> My BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
My Identifier:780222304203
Time: 1468583082




Code
use Switch; 
use strict ;
use warnings;

use Data::Dumper;

my $chunk_separator=q();
local $/ = $chunk_separator;
getFirstIntervalReport('MY_W',780222306003,'up.v.000652',780222304203);


sub getFirstIntervalReport
{
my ($wssmInstType, $expLinkMy, $expStation,$expectedMyFailure) = @_;
my $scan = "on";
# Sort the report files basd on the date in the file name and process each file
my @fileData = <DATA>;
foreach my $input_line (@fileData)
{
print "$input_line \n";
my @my_fields = split /\n/, $input_line ;
my $info_containing_My = grep /My BEING REMOVED/ , $my_fields[0];
my $info_containing_link = grep /LINK BEING REMOVED/ , $my_fields[0];
if( $info_containing_My ) {
print Dumper @my_fields;
if( grep /$expectedMyFailure/ , $my_fields[1]){
print Dumper @my_fields;
}
else { print "Expected My not deleted \n "; }
}

elsif ( $info_containing_link && $scan eq "on" ){
if((grep /$expLinkMy/ , $my_fields[2]) && (grep /$expStation/ ,$my_fields[3])){
$scan = "off" ;
print Dumper @my_fields;
}
else {
$scan = "on" ;
next;
}
}
}
if($scan eq "on") { print " $expLinkMy, $expStation Not Found \n"}
}




__DATA__
<ALERT> ID=7 Link Straight info Loss with count of 10 for
My Identifier:780222304404
Station Address:up.v.000654
Time: 1468581106

<ALERT> ID=17 Link Straight info Loss with count of 10 for
My Identifier:780222304203
Station Address:up.v.000657
Time: 1468581994

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222304404
Station Address:up.v.000654
Time: 1468582162

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222306003
Station Address:up.v.000654
Time: 1468582562

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222304203
Station Address:up.v.000301
Time: 1468583082

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222304203
Station Address:up.v.000654
Time: 1468583082

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222304203
Station Address:up.v.000656
Time: 1468583082

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222304203
Station Address:up.v.000657
Time: 1468583082

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222304203
Station Address:up.v.000656
Time: 1468583082

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222304203
Station Address:up.v.000657
Time: 1468583082

<INFO> LINK BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
for
My Identifier:780222306003
Station Address:up.v.000652
Time: 1468583578

<INFO> My BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
My Identifier:780222304203
Time: 1468583082

<INFO> My BEING REMOVED: Link has had no communication for an extended period of time - being removed from monitoring
My Identifier:780222304454
Time: 1468583082


I dont see any issue with the code and this code runs fine if i fetch the data from a file rather than data block
Also please suggest me if any other approach is superior to this .

Thanks
Tejas


BillKSmith
Veteran

Jul 19, 2016, 10:27 AM

Post #2 of 4 (1726 views)
Re: [Tejas] Data block not being picked in code. [In reply to] Can't Post

The short answer as to why you get different results with DATA than with file is that the 'blank' lines in your data contain space characters. They do not match your $INPUT_RECORD_SEPARATOR. In fact, every line contains trailing whitespace that probably is not in the file.

There are several ways to improve your code. The first is to get rid of your highly nonstandard use of grep. You are using it in scalar context with what appers to be a scalar argument (not allowed). Sufficient study reveals that the argument is a list with only one element - strange! The next time you look at this code, you probably will not remember why this does what you want and if you cannot remember what it is supposed to do, you have a big job of your own making. The match operator does explicitly what you want.

When you store regular expressions in strings, use the qr// operator. This tells your reader that you intend it to be a regex and it tells perl that it does not have to recompile it every time it uses it.

I have not quite worked out exactly what your $scan variable does. I strongly suspect that it can be eliminated by use of the range operator. I admit that this style of code can be hard to write in the first place. The payback is when you have to read it later. It is very easy to understand - again because the code says explicitly what you want.
Good Luck,
Bill


Tejas
User

Jul 19, 2016, 11:52 AM

Post #3 of 4 (1720 views)
Re: [BillKSmith] Data block not being picked in code. [In reply to] Can't Post

Bill,
Thanks for your comments.
Firstly, the data block is nt getting printed as i use use Switch in the code, though its not specified here.

Quote
I have not quite worked out exactly what your $scan variable does. I strongly suspect that it can be eliminated by use of the range operator. I admit that this style of code can be hard to write in the first place. The payback is when you have to read it later. It is very easy to understand - again because the code says explicitly what you want.

Would you please explain how to use range operator, it woul be realy helpful.


Quote
There are several ways to improve your code. The first is to get rid of your highly nonstandard use of grep. You are using it in scalar context with what appers to be a scalar argument (not allowed). Sufficient study reveals that the argument is a list with only one element - strange! The next time you look at this code, you probably will not remember why this does what you want and if you cannot remember what it is supposed to do, you have a big job of your own making. The match operator does explicitly what you want.

i did not get which variable you are talking about .
I will change the greps to regexp's .
Thanks for your comments.

Woul you please help me improving the code, if u find time

Thanks
Tejas


BillKSmith
Veteran

Jul 20, 2016, 11:04 AM

Post #4 of 4 (1691 views)
Re: [Tejas] Data block not being picked in code. [In reply to] Can't Post

Since my last post, I have experimented some and determined that the range operator is not a good option for this application, For future reference, the range operator is documented in the 'Range Operators' section of perldoc perlop. Study the paragraph which starts 'In scalar context...'. It is not easy reading, but I cannot explain it better. At least, it has a lot of examples.

You use grep much the same way in three places.

Code
 
my $info_containing_My = grep /My BEING REMOVED/ , $my_fields[0];

When what you mean is:

Code
my $info_containing_My = $my_fields[0] =~ m/My BEING REMOVED/;

The variable '$info_containing_My' forces grep into scalar context (so it returns the number of matches). The second argument of grep is specified to be a list. Yours is the single scalar '$my_fields[0]'. It is not clear to me why grep does not consider this an error, but it treats it as a list containing only a single element. If there is a match, grep returns 1 (the number of matches). If there is no match, grep returns 0 (again the number of matches). So by pure luck, your code always did what you intended.

My first step in my failed attempt to create a range operator version was to simplify your code so I could understand it better. I removed unnecessary variables. Corrected the scope of others. The three arguments which are used as regular expressions are saved as compiled regular expressions. Most of the other changes had to do with reformatting and adding comments. Perhaps some of it will be useful to you.


Code
use strict; 
use warnings;
use Data::Dumper;

getFirstIntervalReport(
'MY_W', # Wssm Inst Type
780222306003, # Exp Link MY
'up.v.000652', # exp Station
780222304203, # expected My Faillure
);

sub getFirstIntervalReport {
my $expLinkMy = qr/$_[1]/;
my $expStation = qr/$_[2]/;
my $expectedMyFailure = qr/$_[3]/;
my $scan = qq/on/;

INPUT_LINE:
while (my $input_line = do{local $/=q(); <DATA>}) {
print "$input_line \n";
if ( $input_line =~ m/My BEING REMOVED/ && $scan eq 'off' ) {
print Dumper $input_line;
if ( $input_line =~ m/$expectedMyFailure/ ) {
print Dumper $input_line;
next INPUT_LINE
}
print "Expected My not deleted \n ";
next INPUT_LINE;
}

if ( $input_line =~ m/LINK BEING REMOVED/ && $scan eq 'on' ) {
if ( $input_line =~ m/$expLinkMy/
&& $input_line =~ m/$expStation/ )
{
$scan = "off";
print Dumper $input_line;
next INPUT_LINE;
}
$scan = "on";
next INPUT_LINE;
}
}
if ( $scan eq "on" ) { print " $expLinkMy, $expStation Not Found \n" }
return;
}

__DATA__

Good Luck,
Bill

 
 


Search for (options) Powered by Gossamer Forum v.1.2.0

Web Applications & Managed Hosting Powered by Gossamer Threads
Visit our Mailing List Archives