in reply to Trouble iterating through a hash

Hi e9292,

I rewrote your code without changing it too much so that it (a) works as specified and (b) gets rid of lots of unnecessary cruft, (c) primarily your use of use vars (deprecated) and global variables (discouraged).

However please note that you appear to be working with CSV-format files (tab-delimited), and so you would be much safer to read them in with a CSV-parsing module such as Text::CSV_XS which can handle empty fields, blank lines, special characters inside fields, etc.

Also, if you have 500,000 entries, I would suggest storing the output data in a simple RDBMS such as SQLite. This will make working with the data much easier after you collate it.

#!/usr/bin/perl use warnings; use strict; use autodie; my %whole_pedigree; open( my $in, '<', 'wholepedigree_F.txt'); while ( my $line = <$in> ) { chomp $line; my ( $ID, $sire, $dam, $F, $FB, $AHC, $FA ) = split ( /\s+/, $line + ); if ( $ID ) { $whole_pedigree{ $ID } = "$F\t$AHC"; } } close $in; open( my $look_for, '<', 'damF.txt' ); open( my $output, '>', 'output.txt' ); while ( my $line = <$look_for> ) { chomp $line; my ( $damID, $damF, $damAHC, $prog ) = split (/\s+/, $line); if ( $prog && $whole_pedigree{ $prog } ) { print $output join( "\t", $prog, $whole_pedigree{ $prog }, "$ +damID\t$damF\t$damAHC" ), "\n"; } } close $look_for; close $output; print "Done\n";
cat output.txt
3162 0 0 501093 0 0 3163 0 0 2958 0 0 3164 0 0 1895 0 0 3165 0 0 1382 0 0 3166 0 0 2869 0 0

Hope this helps!


The way forward always starts with a minimal test.

Replies are listed 'Best First'.
Re^2: Trouble iterating through a hash
by NetWallah (Canon) on Mar 09, 2017 at 03:38 UTC
    Nice and clean (++).

    The only hesitation I had was that the error checking in OP's "open" statements was not retained.

    open (...) or die "Couldn't open... $!";
    Please add that to your post, so it can be truly exemplary for noobs.

            ...it is unhealthy to remain near things that are in the process of blowing up.     man page for WARP, by Larry Wall

      Error checking is actually taken care of by "use autodie;". I personally don't like to do that because often a die message can explain to the user the context of what is happening in addition to the actual file that couldn't be opened, e.g. "can't open configuration file: $file_name". This sort of thing becomes more important if there is a GUI involved as opposed to a command line.

      Also other "tweaking" of the die message can be done. There is a difference between  die "xyzzy" and die "xyzzy\n" This controls whether or not the user gets the Perl line of code number. Sometimes, it can confuse users if too much info is given with terminology that they don't understand.

      ###### with auto die ###### open XXX, '<', "XXX"; #Can't open 'XXX' for reading: 'No such file or directory' at C:\Proje +cts_Perl\testing\die_messasges.pl line 7 ###### without auto die ### # trailing \n in the die message suppresses the line number. open XXX, '<', "XXX" or die "couldn't open Config file, XXX!\n"; # couldn't open Config file, XXX! open XXX, '<', "XXX" or die "couldn't open XX file!"; #couldn't open XX file! at C:\Projects_Perl\testing\die_messasges.pl l +ine 5. open XXX, '<', "XXX" or die "couldn't open config file XX!, $!"; # couldn't open config file XX!, No such file or directory at C:\Proje +cts_Perl\testing\die_messasges.pl line 6.
      update:
      I didn't show every possibility.
      Some points: 1)autodie is pretty cool, especially for short quick scripts. But, there is no context information. In a complex app, it may not be apparent to the user what this file is about. 2) Add or not the trailing "\n" to a die message to control reporting of Perl line number. 3) Often $! is just confusing noise depending upon the App. I use all of the above options in one situation or another. I can't say: "always do it way #X".
        Nice (++). I did not realize autodie was so clear about the file name , and error message - will use that on my next project. Thanks.

                ...it is unhealthy to remain near things that are in the process of blowing up.     man page for WARP, by Larry Wall