in reply to Re^3: Some one help me with this code.how to make it work.
in thread Some one help me with this code.how to make it work.

I'd be glad to help.

The code is not terrible, on the surface. Frankly, it really only shows you're new to Perl -- no crime in that.

What was in question was whether or not the code was yours.

You still haven't made a convincing argument that it is -- but at least you are now addressing the questions.

So let's step through this, and see where we end up.

Let's start with this:

     tried to write a code to store the details of an employee into a text file as hash(%)

For a newcomer, it is not surprising you simply tried to write the hash into a file directly -- Perl does so many things for us automatically, you might presume it can do this, too.

Sadly, however, this is not a reliable technique. There are ways to make it reliable, but (get used to this, BTW) there's a question you need to answer first:

Do you want to use a Module, or write all the code yourself?

Where we go next depends on your answer.

  • Comment on Re^4: Some one help me with this code.how to make it work.

Replies are listed 'Best First'.
Re^5: Some one help me with this code.how to make it work.
by marinersk (Priest) on Apr 09, 2015 at 11:52 UTC

    There's no wrong answer here. There are a lot of benefits to using a module, but there is a lot to be said for doing it yourself, especially if the goal is to get better at programming in Perl.

    We simply need your decision in order to proceed.

Re^5: Some one help me with this code.how to make it work.
by yedukondalu (Acolyte) on Apr 09, 2015 at 14:06 UTC

    Thanks for your help.. I am not interested in module..I just need to write my code so that i can understand the concepts where to use and when to use.. <\p>

      If the assignment doesn't allow you to use a module, you might start with dbmopen, which will let you tie a hash variable to a file, and then automatically update the file as you make changes to the hash:

      #!/usr/bin/env perl use 5.010; use strict; use warnings; dbmopen(my %h, './database.dbm',0666) or die $!; # open database file $h{mykey} = 'my value'; # save a key/value p +air dbmclose(%h); # close database dbmopen(my %i, './database.dbm',0666) or die $!; # reopen database fi +le say "$_ : $i{$_}" for keys %i; # print key/value pa +irs dbmclose(%i);

      When you're comfortable with that, look into tie, which is meant to supersede the dbm* routines and gives you a more flexible way to do the same sort of thing (I think there may be portability issues with dbmopen, which tie was created to alleviate). If you want a database file that's human-readable, you can use something like YAML or JSON on the backend, but those would require a lot of coding or a module.

      Aaron B.
      Available for small or large Perl jobs and *nix system administration; see my home node.

      aaron_baugher definitely gives you a good direction for research and experimentation with dbmopenand its family of routines.

      If that makes sense to you, feel free to proceed with it and ask questions on anything.

      If dbmopen is confusing you, or confusing to you, let us know. We can find a smaller fire hose to drink from.

        I would also point out that backslashes are not used in HTML tags. You have a <\p> instead of a </p> in your most recent post.

      Summary

      Here are some extremely simplified examples of the basic techniques which would reliably convert a hash to and from a file under relatively reasonable constraints.

      As you requested in private chat, I've avoided the use of modules and deprecated functionality (such as dbmopen).

      Please note that this is not product-grade code -- reading and writing individual records from a data file is a much more efficient use of CPU, memory, and other runtime resources than this slurp/process/spew approach.

      The Slurp/Spew approach simply makes it easier to demonstrate the underlying techniques.

      Design

      In this example, the design is simplistic:

      • Every employee is presumed to have a unique employee ID
      • The employee ID is the primary key for this data
      • The data is presumed to have no tab characters in it
      • The data is presumed to be only text -- no binary data
      • The processing sequence is presumed to be:
        1. The entire contents of the data file are loaded to the hash
        2. The data is processed/manipulated as needed
        3. The entire contents of the hash are written to the file, overwriting it

      Code

      So, without further adieu, a working sample, as requested:

      hashfile1.pl:

      And what code would be complete without a way to see what your data is actually doing (and yet avoiding the use of the otherwise most excellent Data::Dumpand Data::Dumpermodules):

      hashlist1.pl: