in reply to Push records to array during implicit loop and write to file

The implicit loop is messing with your scoping, B::Deparse show you
BEGIN { $^W = 1; } BEGIN { $/ = "\n"; $\ = "\n"; } LINE: while (defined($_ = <ARGV>)) { chomp $_; our(@F) = split(/;/, $_, 0); use strict 'refs'; { my $outfile = 'outfile.txt'; my @result; my $var1 = $F[0]; my $var2 = $F[1]; my $var3 = $F[2]; push @result, "$var1 $var2 $var3"; print "Processed infile line no.: $."; sub END { print 'Array contains: ' . @result . ' element(s).'; writeToFile(\@result, $outfile); } ; } sub writeToFile { my $array_ref = $_[0]; my $filename = $_[1]; die unless open OUTFILE, "> $filename"; foreach $_ (@{$array_ref;}) { print OUTFILE $_; } close OUTFILE; } ; }
Every time you read a line you @result is empty. The implicit loop is best left to oneliners.

See Coping with Scoping

Replies are listed 'Best First'.
[SOLVED] Re^2: Push records to array during implicit loop and write to file
by jospan (Novice) on Jan 12, 2010 at 13:11 UTC
    Thanks for putting me on the right track, Anonymous Monk.

    The problem is now SOLVED! :-)

    By declaring @result private with 'my' it apparantly gets reset every time the script loops through the next line from the infile.

    The solution (probably not a nice one) was to declare @result a global variable with 'our' in stead of 'my'.
      You have a rather restrictive set of requirements. The implicit loop, using these other options like "naF" as well using an END block as you described aren't usually seen.

      I guess it is possible that this is some homework assignment. If it is, then I think this is not a very good one because it uses some features that just aren't used that often.

      A more typical thing would be like shown below. There would be some way to get a "usage statement" if the input command was wrong. The input/output "opens" would be done near the beginning of the program. You don't want to have a program that runs a long time, then bombs because the output permissions or path to the output file means that no result can be output!

      If you want to process multiple files, I show a simple foreach loop below that will do that. There is no need to close a filehandle before you open it to another file.

      Below I show "my @result" just needs to be declared at a higher scope that the input loop. An "our" variable is usually used for situations where a variable needs visibility outside the package it was defined in, which is not the case here.

      Anyway, if your requirement statements aren't driven by a homework assignment, I would do something a lot more straightforward.

      #! usr/bin/perl -w use strict; if (@ARGV == 0) { print "usage: perl test.pl infile [infile]\n"; exit(1); } my $outfile = "outfile.txt"; open (OUTFILE, '>', $outfile) or die "unable to open $outfile : $!\n"; my @result; foreach my $infile (@ARGV) { open (INFILE, '<', $infile) or die "unable to open $infile : $!\n"; while (<INFILE>) { chomp; my (@vars) = split(/;/,$_); push @result, "@vars"; print "Processed $infile line no.: $. vars= @vars\n"; } } print "Result Array contains: " . @result . " element(s).\n"; writeToFile( \@result); sub writeToFile { my $array_ref = shift; foreach ( @{ $array_ref } ) { print OUTFILE "$_\n"; } } __END__ infile.txt: 1;2;3 a;b;c 4;5;6 infile2.txt: X;Y;Z 9;10;11 C:\TEMP>perl newbie3.pl infile.txt infile2.txt Processed infile.txt line no.: 1 vars= 1 2 3 Processed infile.txt line no.: 2 vars= a b c Processed infile.txt line no.: 3 vars= 4 5 6 Processed infile2.txt line no.: 4 vars= X Y Z Processed infile2.txt line no.: 5 vars= 9 10 11 Result Array contains: 5 element(s). C:\TEMP>cat outfile.txt 1 2 3 a b c 4 5 6 X Y Z 9 10 11
        Hi Marshall,
        Thank you very much for taking your time to reply in such depth - that's highly appreciated.

        The problem I'm solving is not a homework assignment but concerns a task at my job that I wish to automate. The AWKish requirement was my own idea bit I see that I need to bend over backwards to fulfill the requirement and the code comes out clumsy and not as elegant as your suggestion.

        In your code and comments I see several good points to observe in my future coding. I shall rewrite my script along the lines suggested by you.

        Thank you for sharing your expertise, experience and tips on good coding style.