Store data into a hash by reading a text file

Hi,

I am trying to parse a text file which contains 2 fields on each row viz. the username and emailid. For e.g my text file looks like:
XYZ,XYZ@ABC.com
JKL,JKL@ABC.com
The delimiter could be anything - a comma or a tab.

I want to parse this file and store the data in key-value pairs in a hash. Keys would be userids and values would email.

Has anyone tried this kinda code in PERL. If yes please do help me out with the code.

Thanks in advance.
-Abhishek

Find more posts tagged with

Comments

Adam Stoller

This is pretty basic Perl code - in fact, this is basically the kind of thing that Perl was originally created to do.

I'd recommend that you pick up a copy of either O'Reilly's "Learning Perl" (if you've never done any [shell] programming) or "Programming Perl" (if you are generally comfortable with programming).

With either of those books in hand, you should be able to figure out the answer to your question very quickly.

I realize I could just *give* you the code - and chances are, someone will - but you won't learn anywhere near as much that way - and building up Per knowledge is valuable, IMO, so I think it better that you actually "learn" it ...

--fish
(Interwoven Senior Technical Consultant)

rollo

Also, if you're running ActivePerl (and probably other flavours), the included HTML documentation is really detailed, covering everything you could want to know. Check perlintro and the perlfaqs especially, and given that you're parsing lines from a text file, perlop. And perlfunc is very useful too.

But for what it's worth (and because I learnt all of my Perl from other people's code in the early days, and this is a construct I use all the time), I'd probably do something like:

open(FILE,'file.txt') or die "Cannot open file: $!";
while(<FILE>) { if($_ =~ /^(.*?)\t(.*?)$/) { %emails = (%emails, $1 => $2) } }
close FILE;

As an attempt to explain, basically, you're opening a file (with error handling), iterating through the file line by line (using the default $_ variable) and testing each line for a match. The caret ^ means the start of the line, $ is the end (before the newline char) and \t is a Tab char so this would be for a tab-delimited file. A dot is any char, * means 0 or more times and ? makes it greedy (read perlre). If the line matches, it adds to a hash, with the first match value ($1) as the key and the second ($2) as the value. You might want to throw a chomp (look in perlfunc) in there before the match line, just for kicks. Of course you'd probably want to build in validation for malformed email addresses and stuff like that as well.

If you need to change lines in the file, I highly recommend the Tie::File module - it enables you to treat a file just like an array. Very handy.

Gurus, feel free to tear my code apart in the name of education Smiley Happy

abhishek_gupta

Hi,

Thanks a lot for the code. Worked perfect. I infact tried a similar piece, which looks like

open(FILE,"$filename");
while (<FILE>)
{
chomp($_);
#user id must be a "word" A-Za-z0-9
if ($_ =~ /\w+/) {
&debuglog("file: $_") if ($DEBUG);
@a = split(/t/, $_);
$hash{$a[0]} = $a[1];
}
}
close(FILE);

Do tell me if there is any better and elegant way of doing it, other than the one you sent and the one above.

Thks.
Abhi

rollo

Looks good to me - I prefer using the pattern-matching method over split as it means you don't have to create those extra variables. In fact you could roll the validation and match into one:

if ($_ =~ /^{\w+?}\t{\w+?}$/) {

the start and end line identifiers are needed otherwise it won't match line by line. Or if you wanted to be tricky, you could do it like this:

if ($_ =~ /^(\w+?)\t(\w+?)\@(\w+?)\.(\w+?)$/) {

which will also check for valid email address structure. The @ and the . have to be escaped, remember. You'd need to reformulate the email address when you put it into the hash with something like

$hash{$1} = "$2\@$3.$4";

If the userid or email is not valid, it would be nice to have an else condition to take care of those (log/debug them).

I noticed a couple of other small things, which you can ignore if you like:

You don't need to double-quote a variable which is on its own - open(FILE,"$filename"); can be open(FILE,$filename); (see perlfaq4: What's wrong with always quoting "$vars''?) and generally chomp is used without a variable - just chomp; on its own, as it uses the default variable ($_) if the arguments are omitted. That's just a style thing though. Lots of Perl functions (split is another) will use the default variable but omitting it at every chance can makes the code harder to read. Also, if you prefer (for clarity) you can omit the parentheses on a 'post-conditional' if:

&debuglog("file: $_") if $DEBUG;

One thing you probably want to get into the habit of doing is keeping variables local within blocks by using 'my'. So your temporary array @a could be created with:

my @a = split(/\t/, $_);

to prevent it becoming global (and you do need \t not t but I guess that's a typo).

I should also say that my previous post had an error in it - a ? in a pattern match prevents the pattern from being 'greedy' (ie match the minimum number of times) not makes it greedy, which is the default.

Finally, hopefully you already do this, but always use -w on the command line when you're testing scripts locally. It's very helpful.

Adam Stoller

You don't need to double-quote a variable which is on its own - open(FILE,"$filename"); can be open(FILE,$filename); (see perlfaq4: What's wrong with always quoting "$vars''?)

While the faq information is true - it's also not very specific with regards to when you're likely to notice any kind of performance difference (I did a test with 6 string variables doing assignments and concatenations with, and without, quoting them - and it wasn't until I got above 100,000 iterations that I started to see some distinction in the benchmark tests).

However, in the case of the example you provided - I'm a strong believer in explicitly showing whether I'm opening a file for reading by using the '<' signifier - and in that case you *must* put quotes around it like:
open(FILE, "<$file");
So you might want to choose a slightly better example.

I also generally recommend the use of quotes around things that are supposed to be paths or filenames because you never know when you're going to run into one of those [often on Windows] paths/files that contains white-space and breaks your otherwise beautiful code.

and generally chomp is used without a variable - just chomp; on its own, as it uses the default variable ($_) if the arguments are omitted.

Actually chomp is often used with variables - both scalars and arrays - though it is also frequently used without for the reason you indicated.

There's an article floating around somewhere entitled something like: Friends don't let friends use chomp espousing the various problems that one can get in if you're not careful. I believe it essentially said that if you cannot be assured of the value of $/ you should not use chomp because it could be changed to some other character and produce very unexpected results.

--fish
(Interwoven Senior Technical Consultant)

rollo

Good point on the spaces in filenames - I haven't encountered that scenario, but I'm sure it will happen sooner or later. IMO always quoting $variables is unnecessary, but as you say, I should have chosen a better example.

As far as chomp, I should have been clearer - of course it can be (and is) used on specific variables, but in this case (taking the $/ (newline, by default) off a line read from a file) it is almost exclusively used without an argument.

Of course, if you match on a line using ^ and $ you don't need to chomp at all, because the $ marks the end of line before the newline anyway. Although that breaks too if $/ changes (as will plenty of other things that rely on it being set to its default) so maybe the best advice is to make sure that if you set $/ to something else (for slurping or suchlike) that you should do it locally to the file or block or whatever, or face the consequences.