That's not the output I was requesting, but it does prove that the var does not "disappear".

Are you using the perl debugger (i.e., do you execute it as 'perl -d yourscript.pl') or are you using some other 3rd party debugger?

Remove the print statement that I had you put in and add this to the end of the script.

Code

END { print Dumper \%type_normalName_cutoff_chromosomes; }

If you get the same output, then that proves that the var is intact to the end of the script.

If your debugger tells you that it doesn't exist or that it's empty, then either your debugger has a bug or your usage of it is flawed.

OK - I did that, and the result is the same, i.e. my variable appears to be there. However, the output file that I generated is not consistent with that - it's empty - and that result is consistent with what I see in the debugger. And if I run the script from a terminal rather than in my debugger, the output file is again inconsistent with the variable existing (i.e. the output file is empty).

The debugger I'm using is third party (Komodo) and I'm running it on Mac OS X.

That's not the output I was requesting, but it does prove that the var does not "disappear".

Are you using the perl debugger (i.e., do you execute it as 'perl -d yourscript.pl') or are you using some other 3rd party debugger?

Remove the print statement that I had you put in and add this to the end of the script.

Code

END { print Dumper \%type_normalName_cutoff_chromosomes; }

If you get the same output, then that proves that the var is intact to the end of the script.

If your debugger tells you that it doesn't exist or that it's empty, then either your debugger has a bug or your usage of it is flawed.

OK - I did that, and the result is the same, i.e. my variable appears to be there. However, the output file that I generated is not consistent with that - it's empty - and that result is consistent with what I see in the debugger. And if I run the script from a terminal rather than in my debugger, the output file is again inconsistent with the variable existing (i.e. the output file is empty).

The debugger I'm using is third party (Komodo) and I'm running it on Mac OS X.

I have not analyzed your code in detail, but it seems to be clear that the problem is with the loop and how you're accessing the hash and not that the var "disappears".

The starting point really should be to get rid of as many of those global vars as possible and declare them in the smallest scope that they require.

Whenever you create a filehandle or directory handle, you should ALWAYS check the return code and take action if the open call fails. You should also use a lexical var for the handle and in the case of a filehandle, use the 3 arg form of open. Do not quote single vars.

Whenever you create a filehandle or directory handle, you should ALWAYS check the return code and take action if the open call fails. You should also use a lexical var for the handle and in the case of a filehandle, use the 3 arg form of open. Do not quote single vars.

see: perldoc -q quoting

Code

opendir my $DIR, $path or die "opendir failed on '$path' $!";

Thanks. I appreciate the comments.

I disagree with the first comment but it's based on biological stuff rather than good perl practice. Basically, those numbers are just like names. 1 means as much as "Fred" would in a different situation, so I think a hash is most appropriate and least likely to lead to errors.

I see the point of the second one. It also fits in to your general criticism of my use of global variables, something that I'll definitely consider.

I see a lot of the point of the third one, but I don't understand the "$!". What is that?

Thanks again for the comments. I definitely have a lot to learn in perl.

I disagree with the first comment but it's based on biological stuff rather than good perl practice.

An array is an ordered list numerically indexed.

A hash is an unordered list which is string indexed.

A hash uses far more memory to hold it's data and since you're working with a large file that is loaded into memory, you should be mindful of the unneeded memory usage.

Following or not following Perl's best coding practices is the difference between good Perl programmers and mediocre or poor Perl coders.

Quote

I see a lot of the point of the third one, but I don't understand the "$!". What is that?

$! holds the error message returned by the OS. So, in the case of opening a filehandle or directory handle, it will tell you the OS's reason why it failed. You can learn about Perl's special variables by reading the perldocs that come with Perl, specifically:

I disagree with the first comment but it's based on biological stuff rather than good perl practice.

An array is an ordered list numerically indexed.

A hash is an unordered list which is string indexed.

A hash uses far more memory to hold it's data and since you're working with a large file that is loaded into memory, you should be mindful of the unneeded memory usage.

Following or not following Perl's best coding practices is the difference between good Perl programmers and mediocre or poor Perl coders.

Quote

I see a lot of the point of the third one, but I don't understand the "$!". What is that?

$! holds the error message returned by the OS. So, in the case of opening a filehandle or directory handle, it will tell you the OS's reason why it failed. You can learn about Perl's special variables by reading the perldocs that come with Perl, specifically: