The hash keys (when printed using Data::Dumper) were displayed within double quotes when the code was ran on different machine. On my machine, the hash keys appear without double quotes.

There are two package variables in Data::Dumper that can modify this behaviour:

$Data::Dumper::Quotekeys or $OBJ->Quotekeys([NEWVAL]) Can be set to a boolean value to control whether hash keys are quoted. A defined false value will avoid quoting hash keys when it looks like a simple string. Default is 1, which will always enclose hash keys in quotes.

$Data::Dumper::Useqq or $OBJ->Useqq([NEWVAL]) When set, enables the use of double quotes for representing string values. Whitespace other than space will be represented as [\n\t\r], "unsafe" characters will be backslashed, and unprintable characters will be output as quoted octal integers. The default is 0.

You should check the other modules you use, maybe one of them changes those package variables without resetting them, propagating the changed behaviour everywhere. BTW, to limit the effect of those variables you can use local.

{
  local $Data::Dumper::Quotekeys = 0;
  print Data::Dumper \%hash; # No quote keys
  sub_from_other_module(); # No quote keys in the calls to Data::Dumpe
+r from the other module
}
print Data::Dumper \%hash; # Quote keys
sub_from_other_module(); # Quote keys as well
[download]

The default behaviour is neither of the cases you have observed though (it's single quotes, not doubles, not none) so that's still surprising.

The hash keys (when printed using Data::Dumper) were displayed within double quotes ...

Please show, don't tell - post some sample input and the actual Data::Dumper output in <code> tags. See also How do I post a question effectively?

Your description is a bit unclear on whether you mean (foo=>3) vs. ("foo"=>3), or ('foo'=>3) vs. ('"foo"'=>3). If it's the former, then Eily has already shown you the variables that control that behavior, although I would have to add that Data::Dumper is a debugging aid and not the best thing to output strings in a reliably consistent format - as long as its output is in Perl syntax it's doing its job.

On the other hand, if it's the latter example, which I am thinking is the case, then I fully agree with Corion's post - the fact that you have to decide between commas and semicolons as separators means you're dealing with CSV files in different formats, so it's reasonable to assume that one input file might say foo;bar;quz and the other "foo","bar","quz". Using Text::CSV will take care of that for you.

Just to point out one other thing: Your BEGIN { my @script_path_dirs = split('/',abs_path($0)); ... can, as far as I can tell, be replaced by the slightly more reliable use FindBin; use lib $FindBin::Bin;.

Sorry for my delayed response and thanks for so many useful replies.

Thanks Corion for your hint. The file Pin_Values.txt actually has a csv format and the tool opens the file using soffice. I now realize that I missed to check if CSV file (Pin_Values.txt) is being processed correctly by soffice on two machines. This could possibly be the reason since the machines might have different soffice setup. I can confirm this by Tuesday as I am currently out and not having access to my system.

Hi haukex, thanks for your tips. Sorry for missing to go through process in pressure to resolve the error. To answer your query, I was referring to ('foo'=>3) vs. ('"foo"'=>3).

Thanks Eily for sharing useful info about Hash key behavior. This will definitely help me in future. However, I did not change any settings that way and therefore I now suspect soffice to be the issue here.

sitecustomize.pl equivalent on Starwberry Perl?
http://www.nntp.perl.org/group/perl.perl5.porters/2007/10/msg129926.html

I didnt know about this until i saw exilepanda's post. I just confirmed that adding $Data::Dumper::Useqq=0; $Data::Dumper::Quotekeys=0; to it did modify Dumpers actions, (so even before the use Data::Dumper; statement). This may be another place to check if it is enabled by your perl

Your "workaround" means with 100% certainty the problem is your code

Perl doesn't magically insert junk into hash keys that requires a programmer to guess at hash keys, that would be insane

Thanks for the response.

Could you please throw some light on why same code for defining a hash would yield hash key as only Key on one system and as "Key" on another? What could be possibly wrong with the code? I have added the subroutine in my post which actually defines the hash %pinList. On this hash I observed unexpected key format on different machine. Am I defining the hash incorrectly?

Without seeing your input data, this is hard to tell. Your code seems to do some wonky CSV parsing here:

                my @pinWords = ();
                if($line =~ m/.*?,.*?,.*/){
                    @pinWords = split(',',$line);
                }
                elsif($line =~ m/.*?;.*?;.*/){
                    @pinWords = split(';',$line);    
                }
[download]

and then you write that value directly into the hash:

...
               $pin =~ s/^\s*|\s*$//g;    #To remove all leading and t
+railing blanks
...
                    $pinList{$pin} = [$pinMaxSDV,$pinMinSDV];
[download]

So my guess is that sometimes your CSV input data has double quotes around the pin and sometimes it does not.

See Text::CSV_XS for CSV parsing.