First some comments on the code that you wrote off of the top of your head. Then discussion of the ways to solve this problem that I'd actually use. The code review will essentially wind up with what Barry gave, so some of you may wish to skip ahead.

Here's what you gave.

\nopen FILE, "myfile.txt";\nwhile(read FILE, $buf, 1024) { $str = $str . $buf; }\nmy @lines = split /\\n/, $str;\nmy %aHash;\nfor my $line (@lines)\n{\n  ($key, $val) = split / /, $line;\n  $aHash{$key} = $val;\n}\n

Not bad. Syntactically correct. Some stylistic errors. It is harder than it needs to be. It has a couple of bugs, only one of which is serious. But not bad for someone who was only thinking of learning Perl under a week ago.

Let's start with

open FILE, "myfile.txt";

As stated in [link|http://www.perldoc.com/perl5.8.4/pod/perlstyle.html|perlstyle], any attempt to open a file should include an error check. Like this:

\nmy $file_name = "myfile.txt";\nopen(FILE, $file_name) or die "Cannot read '$file_name': $!";\n

If I'm being paranoid (eg the file name comes from CGI) I'd use the 3 argument version of open so that a bad file name cannot accidentally run a program:

\nopen(FILE, "<", $file_name) or die "Cannot read '$file_name': $!";\n

Once you've done that, you do the following to get the lines:

\nwhile(read FILE, $buf, 1024) { $str = $str . $buf; }\nmy @lines = split /\\n/, $str;\n

First of all you are going through too much work to read things in by line. What you're doing works, but the built-in <> operator does that. If I wasn't eliminating this section entirely I'd also fix

$str = $str . $buf;

to say

$str .= $buf;

because Perl uses a smart internal buffering algorithm to avoid recopying data when you incrementally build a string. By explicitly recopying a string into itself you defeat that optimization.

Anyways that is going away, so we're left with the last section:

\nfor my $line (@lines)\n{\n  ($key, $val) = split / /, $line;\n  $aHash{$key} = $val;\n}\n

Obviously the fact that you're not removing newlines is a bug - I'd call that serious. We can fix that with an appropriately placed [link|http://www.perldoc.com/perl5.8.4/pod/func/chomp.html|chomp]. And there is a minor bug in that spaces in the value might cause your value to be chopped off, we can fix that with the third argument to [link|http://www.perldoc.com/perl5.8.4/pod/func/split.html|split].

Not a bug, but a stylistic nit is that people in Perl don't tend to use the aHash naming scheme. If you need a reason, mine is that it sometimes helps to mentally read $ as "the", so it isn't natural to be mentally saying, "the a hash". That is obviously unimportant, nor does it matter that I like placing braces differently than you do. So here is what we get:

\nmy $hash;\nforeach my $line (<FILE>) {\n  chomp($line);\n  my ($key, $val) = split / /, $line, 2;\n  $hash{$key} = $val;\n}\n

Also note that I declared every variable that I used. That is important. I'm a big fan of using [link|http://www.perlmonks.org/index.pl?node=strict.pm|strict] to catch any variables that have not been so declared. This catches a lot of my typos.

And a technical note that you could easily miss. This construct actually slurps the whole file into memory before reading any of it. You can avoid that with while like so:

\nmy $hash;\nwhile (my $line = <FILE>) {\n  chomp($line);\n  my ($key, $val) = split / /, $line, 2;\n  $hash{$key} = $val;\n}\n

But wait, why does <> sometimes read the whole file in, and sometimes not? This is a result of a basic design idea in Perl known as context. This is explained in detail in [link|http://www.perldoc.com/perl5.8.4/pod/perlstyle.html|perlstyle]. As a matter of personal opinion I believe this to be a design mistake in Perl, but many others cite it as one of their favorite parts. In any case the idea is that if a construct looks like it wants a list, it gets a list. If it looks like it wants a single thing, it gets a single thing. It is up to each function how it wants to deliver a single thing or a list and [link|http://www.perlmonks.org/index.pl?node_id=347416|no convention exists] on this. You can use [link|http://www.perldoc.com/perl5.8.4/pod/func/wantarray.html|wantarray] to make your functions behave differently in different contexts.

Incidentally the final solution that I gave looks like this:

\nuse strict;\n# time passes\nmy $file_name = "myfile.txt";\nopen(FILE, "<", $file_name) or die "Cannot read '$file_name': $!";\nmy $hash;\nwhile (my $line = <FILE>) {\n  chomp($line);\n  my ($key, $val) = split / /, $line, 2;\n  $hash{$key} = $val;\n}\n

Change variable names and use implicit variables and change the open line in minor ways to get Barry's version. People often throw implicit variables into beginning examples, but I like leaving them out. They are another moving part in something that has enough moving parts to keep track of, wait until you are more comfortable with the rest before using them. Besides which, in real code they don't tend to be used as densely as they can be in the small utilities that people use a demos.

---

But this is the mechanics of how to roll your own wheel. A large part of the strength of Perl is how many pre-built wheels you have to choose from. Your wheel has obvious deficiencies. For instance you can't put a space or a newline in the key, nor can you put a newline in the value. Let me go through some of the wheels that you might choose instead.

For this specific problem there are two basic classes of solutions. One are tools to turn a data structure to/from a string, and the other are tools to have a data structure that looks like it is in memory actually live on disk. I'll include some of both:

• [link|http://search.cpan.org/~ilyam/Data-Dumper-2.121/Dumper.pm|Data::Dumper]: Core Perl module. It turns a reference to a data structure into pretty-printed code that will produce that data structure. There are things that it cannot figure out properly, but most of the time it does well. You can [link|http://www.perldoc.com/perl5.8.4/pod/func/eval.html|eval] the code, or if it is in a file, [link|http://www.perldoc.com/perl5.8.4/pod/func/do.html|do] it. I use this mostly for debugging. I've even seen the output be successfully given to non-programmers for debugging complex calculations.


• [link|http://search.cpan.org/~ams/Storable-2.13/Storable.pm|Storable]: Core Perl module (as of Perl 5.8). It turns Perl data structures into a (not human readable) string representing the data. It has convenience functions to write directly to/from the file for you. If I'm not debugging, this is what I use.
  
  If you will be writing the file on one machine and reading it on another, I strongly advise using nstore rather than having someone else later find out about the pitfalls of store.


• [link|http://search.cpan.org/~ingy/YAML-0.35/YAML.pod|YAML]: A module for converting data structures to/from a simple pretty-printed format. Converters for this format are easy to write and are available in a number of languages. The format makes for nice configuration files, and is also good if you need to cooperate between different languages.


• [link|http://search.cpan.org/~nwclark/perl-5.8.5/lib/AnyDBM_File.pm|AnyDBM_File]: Core Perl module. This is a prototypical example of the second approach that I mentioned. You can make a hash be "tied" to a dbm file which is kept on disk. This module actually is implemented by a variety of back-ends, the worst of which is in Perl's core (SDBM_File - the only one to limit the size of key/value pairs) and my favorite which is not, but is widely used (DB_File - that interfaces to Berkeley DB). I'd strongly advise using one of the back-end modules directly, else you can run into a situation where you install a module, AnyDBM_File automatically switches to that, and you don't know how to get your old data...


• [link|http://search.cpan.org/~jhuckaby/DBM-Deep-0.94/Deep.pm|DBM::Deep]: I mention this mainly to illustrate the limitations of standard dbm implementations. This is like DB_File etc, except that it allows you to build a complex data structure with references to hashes, arrays, etc. Traditional dbms turn references into strings that lose data when you ask for them back. This is a little..smarter.

Cheers,
Ben

That is knowing a specific environment and its tools very well, knowing what issues people tend to run into, and knowing how to present that information.

The initial knowledge is helpful while programming, but is only one needed skill of many that a programmer has to put together at the same time. The skill at exposition makes me look good, but that's a documentation skill, not directly a programming skill.

Furthermore that particular explanation is a variant on one that I've both seen given, and attempted to give, before. It is much easier to come up with a nice way to say something when already you've tried to say that thing a few times. Even if you don't clearly remember how you said it before, the experience guides you.

Cheers,
Ben

There is no better way to learn than exposing yourself to constructive criticism. It isn't always the most fun process, but it is effective.

Just be careful about where you place your ego when you try it: [link|http://www.perlmonks.org/index.pl?node_id=270083|http://www.perlmonks...pl?node_id=270083]

Cheers,
Ben

How to handle errors becomes a coding choice.

At the least you want to notice them and log the information somewhere useful. In a web environment you can just print to STDERR and it goes into the webserver error logs. The warn operator adds the current line, and Carp's carp function will add a stack backtrace. None of this will affect the rest of the execution of the program.

But the way that I like doing it is to make errors fatal with die. And then have in the server configuration a place where fatal errors are trapped with a signal handler for DIE. In development they are displayed on screen and in the log with a stack backtrace. In production the user gets a generic error message and the full error is in the logs. (And you work to keep error logs clean. Do not ignore them.) In production you do not want to show a stack backtrace - this debugging information is very helpful to attackers, allowing them to use standard techniques to convert minor coding errors into full-blown exploits.

Setting this configuration up, of course, takes some wizardry. I'd bet that you can find a good starting example from a co-worker though.

My attitude is that if errors are big and visible, then I'm more likely to catch them, and if I don't then testing does. The more you hide errors, the longer they last in the development process, and the longer they last, the more expensive they become to fix. (There is a lot of research backing up the point that errors caught later cost more. I don't know of any that specifically addressed whether having big visible crashes was a net gain or loss though - all I have is my anecdotal experience that this works pretty well.)

As for the directory path issue, ugh. Getting that kind of environment issue sorted out is always a PITA for me. Luckily Mason makes the actual decision configurable. Unluckily you have to figure out how Mason is set up to configure it.

In your position, I'd strongly be inclined towards getting fairly direct access on the Unix machine. Either by setting up VNC there, or setting up X on your machine, or just sshing and using a command-line environment. It isn't just your view of the path issue, it is also being able to run code out of the webserver environment, testing what modules are installed, etc, etc, etc.

Cheers,
Ben