The map function
in [Perl]
|
Prev: FAQ 4.44 How do I test whether two arrays or hashes are equal?
Next: FAQ 5.3 How do I count the number of lines in a file?
From: Gerry Ford on 23 Apr 2008 21:02 "Jim Cochrane" <allergic-to-spam(a)no-spam-allowed.org> wrote in message news:slrng0t2vg.sbv.allergic-to-spam(a)no-spam-allowed.org... >> I beg to differ. I snipped this from an actual, working perl program. >> How >> do you know which braces need a semicolon after? > > If I remember correctly, line 18 (from your error message) was either > the offending line with the close curly brace missing the ';' or the > line (print ...) below it. So you know where to look because of the > line # in the error message. Of course, now that you know that 'do {}' > blocks need a semicolon after them (right?), you know to look for that > now, too. (Of course, compile error messages will not always report a > line number that is at or very close to the actual problem in the code.) #!/usr/bin/perl use strict; use warnings; use Data::Dumper qw( Dumper); my $killrc = "kill.rc"; my @filter; open (FILE, "<", $killrc) or die ("Cannot open $killrc: $!"); @filter = (); foreach (<FILE>) { chomp; next unless length; next if /^#/o; my $pat; eval ('$pat = qr/$_/') or do {prompt $@; next}; push @filter, $pat; close(FILE); } print @filter; #print STDERR "The list is " . Dumper( @list ) . "\n"; __END__ I'm still confused on the whole }; thing. With this version, I've eliminated the the do{}; If I put a semicolon after the foreach close curly brace, I get no change in behavior in the program. ?? -- "Life in Lubbock, Texas, taught me two things: One is that God loves you and you're going to burn in hell. The other is that sex is the most awful, filthy thing on earth and you should save it for someone you love." ~~ Butch Hancock
From: Gerry Ford on 23 Apr 2008 21:08 "Tad J McClellan" <tadmc(a)seesig.invalid> wrote in message news:slrng0rkck.h5g.tadmc(a)tadmc30.sbcglobal.net... > Gerry Ford <gerry(a)nowhere.ford> wrote: > >> How does a person invoke >> the debugger? > > > perldoc -q debug > > How do I debug my Perl programs? #!/usr/bin/perl use strict; use warnings; use Data::Dumper qw( Dumper); my $killrc = "kill.rc"; my @filter; open (FILE, "<", $killrc) or die ("Cannot open $killrc: $!"); @filter = (); foreach (<FILE>) { chomp; next unless length; next if /^#/o; my $pat; eval ('$pat = qr/$_/') or do {prompt $@; next}; push @filter, $pat; close(FILE); }; print @filter; #print STDERR "The list is " . Dumper( @list ) . "\n"; __END__ In perldoc -q debug, they commend the use of Data::Dumper. I mimicked the syntax in the but perlexe thinks I need to have an explicit package instead. What gives? -- "Life in Lubbock, Texas, taught me two things: One is that God loves you and you're going to burn in hell. The other is that sex is the most awful, filthy thing on earth and you should save it for someone you love." ~~ Butch Hancock
From: Gerry Ford on 23 Apr 2008 21:27 "Uri Guttman" <uri(a)stemsystems.com> wrote in message news:x7bq42v97j.fsf(a)mail.sysarch.com... >>>>>> "GF" == Gerry Ford <gerry(a)nowhere.ford> writes: > [snipped and re-ordered] > my return calls IMPLY A SUB is surrounding it. of course it won't work > as shown. jeez, i can't hold your hand and also blow your nose. think > about the code and don't just copy/run it. You wouldn't want to be anywhere near my infirmities today. Stomach flu. #!/usr/bin/perl use strict; use warnings; my $killrc = "sample.killrc"; sub read_killrc { return unless open(my $file, "<$killrc") ; return map { /^([^#]+)#?$/ && eval{ qr/$1/} || prompt $@, () } <$file> ; } read_killrc; __END__ So, how do I adapt this now to take advantage of the return values of map? I no longer have the option of writing print @filter; ? > GF> # perl mats5.pl 2>text50.txt >text51.txt > > why the redirect of stderr? there is no stderr output. and what is in > the prompt sub? # perl mats7.pl 2>text50.txt >text51.txt This statement is what I call "the goocher." It keeps track of what version I'm running and has a means to redirect stdout and stderr. I should capitalize those. I copy and paste these into the command line. What kind of name is Uri? -- "Life in Lubbock, Texas, taught me two things: One is that God loves you and you're going to burn in hell. The other is that sex is the most awful, filthy thing on earth and you should save it for someone you love." ~~ Butch Hancock
From: Gunnar Hjalmarsson on 23 Apr 2008 21:30 Gerry Ford wrote: > "J�rgen Exner" <jurgenex(a)hotmail.com> wrote in message > news:21mr04pro5k3sqjbebv5g2jq5i0doq42t3(a)4ax.com... >> However, I wonder what you are trying to achive by using eval in the >> first place. I don't see any need for it. > > I could just omit it? It's up to you; I for one do see a need for it: It prevents a fatal error for the case a line is not a valid regular expression. C:\home>type test.pl my @filter; while (<DATA>) { chomp; next unless length; next if /^#/o; my $pat; eval '$pat = qr($_)' or do { warn $@; next }; push @filter, $pat; } print "$_\n" foreach @filter; __DATA__ \w+).+? \s+ C:\home>test.pl Unmatched ) in regex; marked by <-- HERE in m/\w+) <-- HERE .+?/ at (eval 1) line 1, <DATA> line 1. (?-xism:\s+) C:\home> -- Gunnar Hjalmarsson Email: http://www.gunnar.cc/cgi-bin/contact.pl
From: J�rgen Exner on 23 Apr 2008 21:47
"Gerry Ford" <gerry(a)nowhere.ford> wrote: >"J�rgen Exner" <jurgenex(a)hotmail.com> wrote in message >> Man, dude!!! How are we supposed to guess??? You could have told us >> that your beef is not with the functionality of print() but with a >> syntax error in that program! Thank you very much for throwing around >> red herrings. > >My problem was that I thought I had a working script before I added the >print statements. At this point, I'm simply very error-prone. Then it is even more important to follow standard procedures for your own and others sake: 1: what is the expected behaviour? 2: what is the observed behaviour? 3: what code is producing this behaviour? 4: what data is producing this behaviour? Those 4 elements are vital for any reasonable investigation. You supplied 3, were vague about 1, and didn't tell anything about 2 or 4, so people had to use crystal balls and tea leaves to guess. And of course they guessed wrong. > This is my >current version of this script, that I think addresses your criticisms: [most of the code snipped] You are still omitting a precise description of what you expect(1), what you observe (2), and data to run your sample code (4). >my $pat; eval ('$pat = qr/$_/') or do {prompt $@; next}; You still got an 'interesting' do{} sitting around. >How would you indent this? I would open the file in my favourite editor and run a "indent-region" command. >> However, I wonder what you are trying to achive by using eval in the >> first place. I don't see any need for it. >I could just omit it? Think! What is it that you are trying to achieve by using the eval()? You didn't tell us. So how can we answer your question? If you don't tell us then we cannot know what you are trying to do with that eval and therefore cannot tell if the eval serves any purpose to achieve that goal or not. jue |