This is a great question, definite ++. Clearly stated problem, concise code, just all around beautiful. I wish people posted questions like this on clpm.
First, the answers to your questions:
- It was sugessted that I return a reference to a hash, thus conserving some memory. Would that just be, return /%hash?
return \%hash. The backslash is the reference operator. And yes, you definitely should return a reference to a hash here.
When you return a hash, you're not really returning a hash. You say return %hash and perl says "Ok, he wants to return a hash. Let's see, was this function called in list or scalar context? If it was list context, I'll just take all of the keys and values of the hash, push each of them onto the stack, and return. That way the function will return a list, and if the caller assigned something to the return of the function like %hash = function() then that hash will be populated by that list that was returned, just like %hash = ('a','b','c','d'). If the function was called in scalar context, I'll do something really bizarre and return a scalar that looks something like '3/8' which shows the number of used buckets and the total number of buckets in the hash. Because, obviously, people use that information all the time."
As you can probably imagine, pushing every key and value of a hash onto the stack is quite inefficient. You've already built the hash once, you'd like to return that same hash, not make perl build you a whole new one. So you return a reference to the hash, and call the function like my $hash_ref1 = process($file1,$list1).
- In any case, what kind of print statement can I insert to test the contents of each hash, as returned?
use Data::Dumper. It's the easiest way to take a look at the contents of any data structure. Simply `use' it at the top of your program, and then do print Dumper $hash_ref1; and Dumper will give you a nicely formatted look at the hash.
- I can't seem to find any information regarding reading data contained in a hash into DBI? Oh yeah, the reason that I am using a hash is that I would like the keys of the hash to become the column headers in the database table that I create.
The general answer to "How do I store a hash in a database" is "Use Storable". Storable does binary serialization of Perl structures. You'll serialize your hash, and then add that string (the Storable representation of your hash) to the database.
In terms of general advice, I have a few things to point out:
- Your method of testing for the correct number of arguments is not the best way. Instead of making sure that $ARGV[3] isn't equal to the empty string, why not just test to make sure @ARGV has exactly four arguments (or at least four arguments, depending on how flexible you want to be). I.e. if (@ARGV == 4) { ... } else { Print "Usage: ... " }
- Your joins on the command-line arguments aren't doing anything useful. join operates on a list of things, putting them together in one string. You're only giving join the separator and one argument, so it's basically a no-op. It looks like that's OK, though, because you're expecting the arguments to be comma-separated already.
- When you print a usage statement, it's often sensible to use $0 to reflect the way that the script was actually called. Also, in case you change the name of the script later, things won't get out of sync.
- It's hard for me to tell what your eventual goal here is, so it's a little hard for me to advise on what to do next, but it seems to me that a couple of things should probably be changed. Firstly, you'll probably want to choose a more robust way of getting the functionality of exfields.pl than calling it using the magic open. Either set it up so it can be required, or copy the useful functions from it, or turn it into a module, etc. Secondly, I'm not convinced that the way you're structuring your hashes is going to make for easy or even possible merging. I'd restructure somewhere, but without having a better idea of what exfields does and what you want the stuff to look like in the DB, I can't suggest more than that.
-dlc